Saltar al contenido principal
LibreTexts Español

1.4: Marco para la Gestión de Proyectos

  • Page ID
    68497
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)\(\newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    Muchas profesiones diferentes contribuyen a la teoría y práctica de la gestión de proyectos. Ingenieros y arquitectos han estado manejando grandes proyectos desde la prehistoria. Desde aproximadamente la década de 1960, se han realizado esfuerzos para profesionalizar la práctica de la gestión de proyectos como una especialización propia. Hay muchos debates activos en torno a esto: ¿La gestión de proyectos debe ser una profesión de la misma manera que la ingeniería, la contabilidad y la medicina? Éstas cuentan con asociaciones profesionales que certifican a quién se le permite legalmente utilizar el título del puesto, y quién puede ejercer legalmente la profesión. También brindan un nivel de garantía de calidad y disciplina a los miembros que se comportan de manera inapropiada. Otro debate en curso es: ¿Cuánto conocimiento de la industria se requiere de un gerente de proyecto experimentado? ¿Con qué facilidad puede un gerente de proyectos de una industria, digamos, TI, hacer la transición a otra industria como la hostelería?

    Existen dos grandes organizaciones con impacto mundial en la práctica de la gestión de proyectos: el Project Management Institute (PMI), con sede mundial en Estados Unidos, y la International Project Management Association (IPMA), con sede mundial en Suiza. Este libro de texto adopta un enfoque que está más cerca del enfoque del PMI. En este capítulo se incluyen más detalles, junto con una sección sobre la oficina de gestión de proyectos.

    Resumen del Instituto de Gestión de Proyectos

    Cinco voluntarios fundaron el Instituto de Gestión de Proyectos (PMI) en 1969. Su objetivo inicial era establecer una organización donde los miembros pudieran compartir sus experiencias en la gestión de proyectos y discutir temas. Hoy en día, PMI es una asociación profesional de gestión de proyectos sin fines de lucro y la organización más reconocida en términos de promover las mejores prácticas de gestión de proyectos. PMI se formó para servir a los intereses de la industria de gestión de proyectos. La premisa de PMI es que las herramientas y técnicas de gestión de proyectos son comunes incluso entre la aplicación generalizada de proyectos desde el software hasta la industria de la construcción. PMI comenzó a ofrecer el examen de certificación Project Management Professional (PMP) en 1984. A pesar de que la gente tardó un tiempo en darse cuenta, ahora más de 590.000 individuos en todo el mundo ostentan la designación PMP.

    Para ayudar a mantener los términos y conceptos de gestión de proyectos claros y consistentes, PMI presentó el libro Una guía para el Cuerpo de Conocimiento de la Gestión de Proyectos (Guía PMBOK) en 1987. Se actualizó en 1996, 2000, 2004, 2009, y más recientemente en 2013 como quinta edición. En la actualidad, hay más de un millón de ejemplares de la Guía PMBOK en circulación. El prestigioso Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) lo ha adoptado como su estándar de gestión de proyectos. En 1999 PMI fue acreditado como desarrollador de estándares del American National Standards Institute (ANSI) y además tiene la distinción de ser la primera organización en tener su programa de certificación lograr el reconocimiento de la Organización Internacional de Normalización (ISO) 9001. En 2008, la organización reportó más de 260 mil miembros en más de 171 países. PMI tiene su sede en Pensilvania, Estados Unidos, y también tiene oficinas en Washington, DC, y en Canadá, México y China, además de tener centros regionales de servicios en Singapur, Bruselas (Bélgica) y Nueva Delhi (India). Recientemente, se abrió una oficina en Mumbai (India).

    Debido a la importancia de los proyectos, la disciplina de la gestión de proyectos se ha convertido en un cuerpo de conocimiento de trabajo conocido como PMBOK — Project Management Body of Knowledge. El PMI se encarga de desarrollar y promover el PMBOK. PMI también administra un programa de certificación profesional para gerentes de proyectos, el PMP. Entonces, si quieres basarte en la gestión de proyectos, PMBOK es el lugar para comenzar, y si quieres hacer de la gestión de proyectos tu profesión, entonces deberías considerar convertirte en un PMP.

    Entonces, ¿qué es PMBOK?

    PMBOK es el conocimiento fundamental que necesitas para gestionar un proyecto, categorizado en 10 áreas de conocimiento:

    1. Gestión de la integración: Los proyectos tienen todo tipo de actividades en marcha y existe la necesidad de mantener el “todo” en movimiento colectivo, integrando todas las dinámicas que tienen lugar. La gestión de la integración consiste en desarrollar la carta del proyecto, la declaración de alcance y el plan para dirigir, administrar, monitorear y controlar el cambio del proyecto.
    2. Alcance de gestión: Los proyectos deben tener un parámetro o alcance definido, y este debe desglosarse y gestionarse a través de una estructura de desglose del trabajo o EDT. La gestión del alcance consiste en planeación, definición, creación de EDT, verificación y control.
    3. Gestión de tiempo/horario: Los proyectos tienen un inicio definido y una fecha de finalización definida. Por lo tanto, existe la necesidad de administrar el tiempo presupuestado de acuerdo a un cronograma del proyecto. La gestión del tiempo/horario se trata de definición, secuenciación, estimación de recursos y duración, desarrollo de horarios y control de horarios.
    4. Gestión de costos: Los proyectos consumen recursos, y por lo tanto, existe la necesidad de gestionar la inversión con la realización de crear valor (es decir, los beneficios derivados superan la cantidad gastada). La administración de costos se trata de planificación de recursos, estimación de costos, presupuestación y control.
    5. Gestión de la calidad: Los proyectos involucran entregables específicos o productos de trabajo. Estos entregables deben cumplir con los objetivos del proyecto y los estándares de desempeño. La gestión de la calidad se trata de planificación de la calidad, aseguramiento de la calidad y control
    6. Gestión de recursos humanos: Los proyectos consisten en equipos y es necesario administrar equipo (s) del proyecto durante el ciclo de vida del proyecto. Encontrar a las personas adecuadas, administrar sus resultados y mantenerlos a tiempo es una gran parte de la gestión de un proyecto. La gestión de recursos humanos consiste en la planeación de recursos humanos, la contratación y el desarrollo y gestión de un equipo de proyecto.
    7. Gestión de la comunicación: Los proyectos invariablemente tocan a mucha gente, no solo a los usuarios finales (clientes) que se benefician directamente de los resultados del proyecto. Esto puede incluir participantes en el proyecto, gerentes que supervisan el proyecto y partes interesadas externas que tienen interés en el éxito del proyecto. La gestión de la comunicación se refiere a la planificación de las comunicaciones, la distribución de la información, la presentación de informes
    8. Gestión del riesgo: Los proyectos son un proceso impulsado por el descubrimiento, a menudo descubriendo nuevas necesidades de los clientes e identificando problemas críticos que no se revelaron previamente. Los proyectos también encuentran eventos inesperados, como la renuncia de los miembros del equipo del proyecto, los recursos presupuestados cambian repentinamente, la organización se vuelve inestable y se introducen nuevas tecnologías. Existe una necesidad real de identificar adecuadamente diversos riesgos y manejarlos. La gestión del riesgo consiste en planificación e identificación de riesgos, análisis de riesgos (cualitativo y cuantitativo), planificación de respuesta al riesgo (acción) y monitoreo y control de riesgos.
    9. Gestión de compras: Los proyectos procuran los servicios de proveedores y contratistas externos, incluyendo la compra de equipos. Es necesario administrar cómo se seleccionan y administran los proveedores dentro del ciclo de vida del proyecto. La gestión de compras consiste en planes de adquisición y contratación, respuestas y selecciones de los vendedores, administración de contratos y cierre de contratos.
    10. Gestión de grupos de interés: Cada proyecto impacta a personas y organizaciones y es impactado por personas y organizaciones. Identificar a estos grupos de interés temprano, y a medida que surgen y cambian a lo largo del proyecto, es un factor clave de éxito. La gestión de grupos de interés consiste en identificar a los grupos de interés, su nivel de interés y su potencial para influir en el proyecto; y gestionar y controlar las relaciones y comunicaciones entre los grupos de interés y el proyecto.

    Este es el gran marco para gestionar proyectos y si quieres ser efectivo en la gestión de proyectos, entonces necesitas ser efectivo en la gestión de cada una de las 10 áreas de conocimiento que componen PMBOK (ver Figura 4.1)

    Figura 4.1: Modelo PM Star sugerido por GeekDisplaced

    La certificación en gestión de proyectos está disponible en el PMI, PRINCE2, ITIL, Critical Chain y otros. Las metodologías ágiles de gestión de proyectos (Scrum, programación extrema, Lean Six Sigma, otras) también cuentan con certificaciones.

    Introducción a las Áreas de Conocimiento de Gestión de Proyectos

    Como se discutió anteriormente, los proyectos se dividen en componentes, y un gerente de proyecto debe estar bien informado en cada área. Cada una de estas áreas de conocimiento se explorará con mayor profundidad en capítulos posteriores. Por ahora, vamos a verlas con un poco más de detalle para prepararte para los capítulos que siguen.

    Puesta en marcha e integración de proyectos

    La puesta en marcha de un proyecto es similar a la puesta en marcha de una nueva organización. El líder del proyecto desarrolla la infraestructura del proyecto utilizada para diseñar y ejecutar el proyecto. El equipo de gestión del proyecto debe desarrollar una alineación entre las principales partes interesadas, aquellos que tienen una participación o interés, en el proyecto durante las primeras fases o fases de definición del proyecto. El gerente del proyecto llevará a cabo una o más reuniones de inicio o sesiones de alineación para reunir a las distintas partes del proyecto y comenzar la formación de equipos del proyecto requerida para operar de manera eficiente durante el proyecto.

    Durante la puesta en marcha del proyecto, el equipo de gestión del proyecto refina el alcance del trabajo y desarrolla un cronograma preliminar y un presupuesto conceptual. El equipo del proyecto construye un plan para ejecutar el proyecto basado en el perfil del proyecto. El plan de desarrollo y seguimiento del cronograma detallado, el plan de adquisiciones y el plan de construcción del presupuesto y estimación y seguimiento de los costos se desarrollan durante la puesta en marcha. Los planes de tecnología de la información, comunicación y seguimiento de la satisfacción del cliente también se desarrollan durante la fase de puesta en marcha del proyecto.

    Los diagramas de flujo, diagramas y matrices de responsabilidad son herramientas para capturar los procesos de trabajo asociados con la ejecución del plan del proyecto. El primer borrador del manual de procedimientos del proyecto captura los conocimientos históricos e intuitivos que los miembros del equipo aportan al proyecto. El desarrollo y revisión de estos procedimientos y procesos de trabajo contribuyen al desarrollo de la estructura organizativa del proyecto.

    Este suele ser un momento emocionante en un proyecto donde todas las cosas son posibles. El equipo de gestión del proyecto está trabajando muchas horas desarrollando el plan inicial, dotando de personal al proyecto y construyendo relaciones con el cliente. El director del proyecto establece el tono del proyecto y establece expectativas para cada uno de los miembros del equipo del proyecto. La fase de inicio del proyecto en proyectos complejos puede ser caótica, y hasta que se desarrollen los planes, el gerente del proyecto se convierte en la fuente de información y dirección. El gerente del proyecto crea un entorno que alienta a los miembros del equipo a participar plenamente en el proyecto y fomenta enfoques innovadores para desarrollar el plan del proyecto.

    Alcance del Proyecto

    El alcance del proyecto es un documento que define los parámetros —factores que definen un sistema y determinan su comportamiento— del proyecto, qué trabajo se realiza dentro de los límites del proyecto y el trabajo que está fuera de los límites del proyecto. El alcance del trabajo (SOW) suele ser un documento escrito que define qué trabajo se realizará al final del proyecto, los entregables del proyecto. El alcance del proyecto define lo que se hará, y el plan de ejecución del proyecto define cómo se realizará el trabajo.

    Ninguna plantilla funciona para todos los proyectos. Algunos proyectos tienen un alcance de trabajo muy detallado, y algunos tienen un breve documento resumido. La calidad del alcance se mide por la capacidad del director del proyecto y las partes interesadas del proyecto para desarrollar y mantener una comprensión común de qué productos o servicios entregará el proyecto. El tamaño y detalle del alcance del proyecto está relacionado con el perfil de complejidad del proyecto. Un proyecto más complejo a menudo requiere un documento de alcance más detallado y completo.

    De acuerdo con el PMI, la declaración de alcance debe incluir lo siguiente:

    • Descripción del alcance
    • Criterios de aceptación
    • Entregables del proyecto
    • Exclusiones de proyectos
    • Restricciones del proyecto
    • Supuestos del proyecto

    El documento de alcance es la base para el acuerdo de todas las partes. Un documento claro del alcance del proyecto también es fundamental para gestionar el cambio en un proyecto. Dado que el alcance del proyecto refleja qué trabajo se realizará en el proyecto, cualquier cambio en las expectativas que no sea capturado y documentado crea la oportunidad de confusión. Una de las tendencias más comunes en los proyectos es la expansión incremental en el alcance del proyecto. Esta tendencia está etiquetada como “fluencia de alcance”. La fluencia del alcance amenaza el éxito de un proyecto porque los pequeños aumentos en el alcance requieren recursos adicionales que no estaban en el plan. Aumentar el alcance del proyecto es una ocurrencia común, y se realizan ajustes en el presupuesto y cronograma del proyecto para dar cuenta de estos cambios. La fluencia del alcance ocurre cuando estos cambios no se reconocen o no se administran. La capacidad de un gerente de proyecto para identificar posibles cambios suele estar relacionada con la calidad de los documentos de alcance.

    Se producen eventos que requieren que el alcance del proyecto cambie. Los cambios en el mercado pueden requerir cambios en el diseño de un producto o el momento de la entrega del producto. Los cambios en el equipo directivo del cliente o la salud financiera del cliente también pueden resultar en cambios en el alcance del proyecto. Los cambios en el cronograma del proyecto, el presupuesto o la calidad del producto tendrán un efecto en el plan del proyecto. Generalmente, cuanto más tarde en el proyecto se produzca el cambio, mayor será el incremento de los costos del proyecto. Establecer un sistema de gestión de cambios para el proyecto que capture los cambios en el alcance del proyecto y asegure que estos cambios sean autorizados por el nivel apropiado de gestión en la organización del cliente es responsabilidad del gerente del proyecto. El gerente del proyecto también analiza el costo y el impacto del horario de estos cambios y ajusta el plan del proyecto para reflejar los cambios autorizados por el cliente. Los cambios en el alcance pueden hacer que los costos aumenten o disminuyan.

    Programación del Proyecto y Gestión del Tiempo

    La definición de éxito del proyecto a menudo incluye completar el proyecto a tiempo. El desarrollo y la gestión de un cronograma de proyecto que concluya el proyecto a tiempo es responsabilidad primordial del gerente del proyecto, y completar el proyecto a tiempo requiere el desarrollo de un plan realista y la gestión efectiva del plan. En proyectos más pequeños, los gerentes de proyectos pueden liderar el desarrollo del plan del proyecto y construir un cronograma para cumplir con ese plan. En proyectos más grandes y complejos, un equipo de control de proyectos que se enfoca tanto en los costos como en las funciones de planificación y control de horarios ayudará al equipo de gestión del proyecto a desarrollar el plan y rastrear el progreso con respecto al plan.

    Para desarrollar el cronograma del proyecto, el equipo del proyecto realiza un análisis del alcance del proyecto, el contrato y otra información que ayuda al equipo a definir los entregables del proyecto. Con base en esta información, el equipo del proyecto desarrolla un cronograma de hitos. El calendario de hitos establece fechas clave a lo largo de la vida de un proyecto que deben cumplirse para que el proyecto termine a tiempo. Las fechas clave a menudo se establecen para cumplir con obligaciones contractuales o intervalos establecidos que reflejen los avances adecuados para el proyecto. Para proyectos menos complejos, un cronograma de hitos puede ser suficiente para rastrear el progreso del proyecto. Para proyectos más complejos, se requiere un cronograma más detallado.

    Para desarrollar un cronograma más detallado, el equipo del proyecto primero desarrolla una estructura de desglose del trabajo (EDT), una descripción de las tareas dispuestas en capas de detalle. Aunque el alcance del proyecto es el documento principal para desarrollar la EDT, la EDT incorpora todos los entregables del proyecto y refleja cualquier documento o información que aclare los entregables del proyecto. Desde la EDT se desarrolla un plan de proyecto. El plan del proyecto enumera las actividades que son necesarias para llevar a cabo el trabajo identificado en la EDT. Cuanto más detallada sea la EDT, más actividades se identifican para realizar el trabajo.

    Después de que el equipo del proyecto identifique las actividades, el equipo secuencia las actividades de acuerdo con el orden en que se van a realizar las actividades. Un resultado del proceso de trabajo es el diagrama lógico del proyecto. El diagrama lógico representa la secuencia lógica de las actividades necesarias para completar el proyecto. El siguiente paso en el proceso de planeación es desarrollar una estimación del tiempo que tomará realizar cada actividad o la duración de la actividad. Algunas actividades deben realizarse de manera secuencial, y algunas actividades se pueden realizar simultáneamente. El proceso de planeación crea un cronograma del proyecto al programar las actividades de una manera que utilice los recursos del proyecto de manera efectiva y eficiente y complete el proyecto en el menor tiempo posible.

    En proyectos más grandes, se crean varios caminos que representan una secuencia de actividades desde el principio hasta el final del proyecto. El camino más largo hasta la finalización del proyecto es el camino crítico. Si la ruta crítica toma menos tiempo del permitido por el cliente para completar el proyecto, el proyecto tiene una flotación total positiva o holgura del proyecto. Si la fecha de finalización del proyecto del cliente precede a la fecha de finalización de la ruta crítica calculada, el proyecto tiene un flotante negativo. Comprender y administrar las actividades en el camino crítico es una habilidad importante para la gestión de proyectos.

    Para gestionar con éxito un proyecto, el gerente de proyecto también debe saber cómo acelerar un cronograma para compensar eventos imprevistos que retrasan actividades críticas. Compresión, caída: el horario es un término que se utiliza para describir las técnicas utilizadas para acortar el cronograma del proyecto. Durante la vida del proyecto, a menudo ocurren conflictos de programación, y el gerente del proyecto es responsable de reducir estos conflictos mientras mantiene la calidad del proyecto y cumple con los objetivos de costos.

    Costos del Proyecto

    La definición de éxito del proyecto a menudo incluye completar el proyecto dentro del presupuesto. Desarrollar y controlar un presupuesto de proyecto que logre los objetivos del proyecto es una habilidad crítica de gestión de proyectos. Aunque los clientes esperan que el proyecto se ejecute de manera eficiente, las presiones de costos varían en los proyectos. En algunos proyectos, la fecha de finalización o finalización del proyecto es el mayor contribuyente a la complejidad del proyecto. El desarrollo de un nuevo medicamento para abordar un problema crítico de salud, la producción de un nuevo producto que generará un flujo de caja crítico para una empresa y la ventaja competitiva de que una empresa sea la primera en el mercado con una nueva tecnología son ejemplos de proyectos con presiones programadas que anulan costos del proyecto.

    La exactitud del presupuesto del proyecto está relacionada con la cantidad de información conocida por el equipo del proyecto. En las primeras etapas del proyecto, a menudo falta la cantidad de información necesaria para elaborar un presupuesto detallado. Para abordar la falta de información, el equipo del proyecto desarrolla diferentes niveles de estimaciones presupuestarias del proyecto. La estimación conceptual (o “estimación de estadio de béisbol”) se desarrolla con la menor cantidad de conocimiento. El principal insumo en la estimación conceptual es el conocimiento experto o la experiencia pasada. Un gerente de proyecto que haya ejecutado un proyecto similar en el pasado puede usar esos costos para estimar los costos del proyecto actual.

    Cuando se conoce más información, el equipo del proyecto puede desarrollar una estimación aproximada de orden de magnitud (ROM). Información adicional como los pies cuadrados aproximados de un edificio, la capacidad de producción de una planta y el número aproximado de horas necesarias para desarrollar un programa de software pueden proporcionar una base para proporcionar una estimación de ROM. Después de que el diseño de un proyecto esté más completo, se puede desarrollar una estimación detallada del proyecto. Por ejemplo, cuando el equipo del proyecto conoce el número de habitaciones, el tipo de materiales y la ubicación del edificio de una vivienda, pueden proporcionar una estimación detallada. Una estimación detallada no es una oferta.

    Se rastrea el costo del proyecto en relación con el avance de la obra y la estimación para su realización. Con base en la estimación de costos, el costo del trabajo realizado se compara con el costo presupuestado para ese trabajo. Si el costo es significativamente mayor o menor, el equipo del proyecto explora las razones de la diferencia entre los costos esperados y los costos reales.

    Los costos del proyecto pueden desviarse del presupuesto debido a que los precios en el mercado eran diferentes de lo que se esperaba. Por ejemplo, los costos estimados para la madera en un proyecto de vivienda pueden ser superiores a los presupuestados o el costo por hora de la mano de obra puede ser menor que el presupuestado. Los costos del proyecto también pueden desviarse según el desempeño del proyecto. Por ejemplo, un equipo de proyecto estimó que el diseño de acero para un puente sobre un río tomaría 800 horas de trabajo, pero en realidad se gastaron 846 horas. El equipo del proyecto captura la desviación entre los costos presupuestados para el trabajo y el costo real del trabajo, revisa la estimación según sea necesario y toma medidas correctivas si la desviación parece reflejar una tendencia.

    El gerente del proyecto es responsable de asegurar que el equipo del proyecto desarrolle estimaciones de costos basadas en la mejor información disponible y las revisa a medida que se disponga de información nueva o mejor. El gerente del proyecto también es responsable de rastrear los costos contra el presupuesto y realizar un análisis cuando los costos del proyecto se desvían significativamente de la estimación del proyecto. Luego, el gerente del proyecto toma las medidas correctivas adecuadas para garantizar que el desempeño del proyecto coincida con el plan revisado del proyecto.

    Calidad del Proyecto

    La calidad del proyecto se centra en el producto final o los entregables del servicio que reflejan el propósito del proyecto. El gerente del proyecto es responsable de desarrollar un enfoque de ejecución de proyectos que proporcione una comprensión clara de los entregables esperados del proyecto y las especificaciones de calidad. El gerente de proyecto de un proyecto de construcción de viviendas no solo necesita entender qué habitaciones de la casa serán alfombradas sino también qué grado de alfombra se necesita. Una habitación con un alto volumen de tráfico necesitará una alfombra de alto grado.

    El gerente del proyecto es responsable de desarrollar un plan de calidad del proyecto que defina las expectativas de calidad y asegure que se cumplan las especificaciones y expectativas. Desarrollar una buena comprensión de los entregables del proyecto a través de la documentación de especificaciones y expectativas es fundamental para un plan de buena calidad. Los procesos para asegurar que se cumplan las especificaciones y expectativas se integran en el plan de ejecución del proyecto. Así como el presupuesto del proyecto y las fechas de finalización pueden cambiar a lo largo de la vida de un proyecto, las especificaciones del proyecto también pueden cambiar. Los cambios en las especificaciones de calidad generalmente se administran en el mismo proceso que los cambios de costos o horarios. Se analiza el impacto de los cambios para determinar su impacto en el costo y el cronograma, y con las aprobaciones adecuadas, se realizan cambios en el plan de ejecución del proyecto.

    La guía A Guide to the Project Management Body of Knowledge (PMBOK Guide) del PMI tiene un extenso capítulo sobre la gestión de la calidad del proyecto. El material que se encuentra en este capítulo sería similar al material que se encuentra en un buen texto de gestión operativa.

    Si bien cualquiera de las técnicas de gestión de calidad diseñadas para hacer mejoras incrementales en los procesos de trabajo pueden aplicarse a un proceso de trabajo de proyecto, el carácter de un proyecto (único y de duración relativamente corta) hace que las pequeñas mejoras sean menos atractivas en los proyectos. La reelaboración de proyectos, al igual que con las operaciones de fabricación, aumenta el costo del producto o servicio y, a menudo, aumenta el tiempo necesario para completar las actividades reelaboradas. Debido a las limitaciones de duración de un proyecto, el desarrollo de las habilidades, materiales y procesos de trabajo apropiados al principio del proyecto es fundamental para el éxito del proyecto. En proyectos más complejos, se dedica tiempo a desarrollar un plan para comprender y desarrollar los niveles adecuados de habilidades y procesos de trabajo.

    Las organizaciones de gestión de proyectos que ejecutan varios tipos similares de proyectos pueden encontrar herramientas de mejora de procesos útiles para identificar y mejorar los procesos de referencia utilizados en sus proyectos. Las herramientas de mejora de procesos también pueden ser útiles para identificar oportunidades de mejora de costos y horarios. Las oportunidades de mejora deben encontrarse rápidamente para influir en el desempeño del proyecto. La inversión en tiempo y recursos para encontrar mejoras es mayor durante las primeras etapas del proyecto, cuando el proyecto se encuentra en las etapas de planeación. Durante etapas posteriores del proyecto, a medida que aumentan las presiones para cumplir con los objetivos del calendario del proyecto, la cultura del proyecto es menos propicia para realizar cambios en los procesos de trabajo.

    Otra oportunidad para aplicar herramientas de mejora de procesos es en proyectos que tienen procesos repetitivos. Un contratista de vivienda que está construyendo varias casas idénticas puede beneficiarse de evaluar los procesos de trabajo en las primeras casas para explorar las oportunidades disponibles para mejorar los procesos de trabajo. La inversión de $1,000 en un proceso de trabajo que ahorra $200 por casa es una buena inversión siempre y cuando el contratista esté construyendo más de cinco casas.

    Equipo del Proyecto: Recursos Humanos y Comunicaciones

    Dotación de personal al proyecto con las habilidades adecuadas, en el lugar correcto y en el momento adecuado es una responsabilidad importante del equipo de gestión del proyecto. El proyecto suele tener dos tipos de miembros del equipo: gerentes funcionales y gerentes de procesos. Los gerentes funcionales y el equipo se enfocan en la tecnología del proyecto. En un proyecto de construcción, los gerentes funcionales incluirían al gerente de ingeniería y a los superintendentes de construcción. En un proyecto de capacitación, el gerente funcional incluiría a los formadores profesionales; en un proyecto de tecnología de la información, los gerentes de desarrollo de software serían gerentes funcionales. El equipo de gestión de proyectos también incluye gerentes de procesos de proyectos. El equipo de controles del proyecto incluiría gerentes de procesos que tienen experiencia en estimación, seguimiento de costos, planificación y programación. El gerente de proyecto necesita experiencia funcional y de procesos para planificar y ejecutar un proyecto exitoso.

    Debido a que los proyectos son temporales, el plan de dotación de personal para un proyecto generalmente refleja tanto los objetivos a largo plazo de los miembros calificados del equipo necesarios para el proyecto como el compromiso a corto plazo que refleja la naturaleza del proyecto. Las fechas exactas de inicio y finalización de los miembros del equipo a menudo se negocian para satisfacer mejor las necesidades de las personas y el proyecto. El plan de dotación de personal también está determinado por las diferentes fases del proyecto. Los miembros del equipo necesarios en las fases iniciales o conceptuales del proyecto a menudo no son necesarios durante las fases posteriores o fases de cierre del proyecto. Los miembros del equipo necesarios durante la fase de implementación a menudo no son necesarios durante las fases conceptuales o de cierre. Cada fase tiene requisitos de personal, y la dotación de personal de un proyecto complejo requiere una planeación detallada para tener las habilidades adecuadas, en el lugar correcto, en el momento adecuado.

    Por lo general, un equipo central de gestión de proyectos se dedica al proyecto desde la puesta en marcha hasta el cierre. Este equipo central incluiría a miembros del equipo de gestión del proyecto: gerente de proyecto, controles de proyectos, adquisiciones de proyectos y miembros clave de la gestión de la función o expertos en la tecnología del proyecto. Aunque los proyectos más largos pueden experimentar más rotación de equipo que los proyectos más cortos, es importante en todos los proyectos tener miembros del equipo que puedan brindar continuidad a través de las fases del proyecto.

    Por ejemplo, en un gran proyecto de edificio comercial, el equipo de ingeniería civil que diseña la obra del sitio donde se construirá el edificio haría su mayor contribución durante las primeras fases del diseño. El jefe de ingeniería civil aportaría diferentes especialidades de ingeniería civil según fueran necesarias. A medida que los trabajos de ingeniería civil se completan y la ingeniería estructural está en marcha, una gran parte de los ingenieros civiles serían liberados del proyecto. Los gerentes funcionales, el gerente de ingeniería y el jefe de ingeniería civil proporcionarían experiencia durante toda la duración del proyecto, abordando las preguntas técnicas que puedan surgir y abordar las solicitudes de cambio.

    Los miembros del equipo del proyecto pueden ser asignados al proyecto desde varias fuentes diferentes. La organización que organiza el proyecto puede asignar gerentes y personal talentosos de unidades funcionales dentro de la organización, contratar con individuos o agencias a puestos de personal en el proyecto, contratar temporalmente personal para el proyecto o usar cualquier combinación de estas opciones de personal. Este enfoque de dotación de personal permite al gerente de proyecto crear la cultura organizacional del proyecto. Algunas culturas de proyectos están más estructuradas y orientadas a los detalles, y otras están menos estructuradas con roles y requisitos de comunicación menos formales. El tipo de cultura que crea el gerente del proyecto depende en gran medida del tipo de proyecto.

    Comunicaciones

    Completar un proyecto complejo con éxito requiere trabajo en equipo, y el trabajo en equipo requiere una buena comunicación entre los miembros del equipo. Si esos miembros del equipo trabajan en el mismo edificio, pueden organizar reuniones regulares, simplemente pasar por el espacio de oficina del otro para obtener una respuesta rápida, o incluso discutir un proyecto informalmente en otras funciones de oficina. Muchos proyectos complejos en la economía global actual involucran a miembros del equipo de ubicaciones ampliamente separadas, y los tipos de reuniones que funcionan dentro del mismo edificio no son posibles. Los equipos que utilizan métodos electrónicos de comunicación sin reuniones presenciales se denominan equipos virtuales.

    La comunicación se puede dividir en dos categorías: síncrona y asíncrona. Si todas las partes de la comunicación están tomando parte en el intercambio al mismo tiempo, la comunicación es sincrónica. Una llamada telefónica en conferencia es un ejemplo de comunicación sincrónica. Cuando los participantes no interactúan al mismo tiempo, la comunicación es asíncrona. (La letra a al principio de la palabra significa no.) Las tecnologías de comunicación requieren una variedad de dispositivos compatibles, software y proveedores de servicios, y la comunicación con un equipo virtual global puede involucrar muchas zonas horarias diferentes. Establecer comunicaciones efectivas requiere un plan de comunicaciones.

    Riesgo del Proyecto

    El riesgo existe en todos los proyectos. El papel del equipo de gestión del proyecto es comprender los tipos y niveles de riesgos en el proyecto y luego desarrollar e implementar planes para mitigar estos riesgos. El riesgo representa la probabilidad de que ocurra un evento durante la vida del proyecto que afecte negativamente el logro de las metas del proyecto. El tipo y la cantidad de riesgo varía según el tipo de industria, la complejidad y la fase del proyecto. El plan de riesgo del proyecto también reflejará el perfil de riesgo del director del proyecto y los actores clave. Las personas tienen diferentes niveles de confort con riesgo, y algunos miembros del equipo del proyecto serán más reacios al riesgo que otros.

    El primer paso para desarrollar un plan de gestión de riesgos implica identificar los riesgos potenciales del proyecto. Algunos riesgos son fáciles de identificar, como el potencial de una tormenta dañina en el Caribe, y algunos son menos obvios. Muchas industrias o empresas tienen listas de verificación de riesgos desarrolladas a partir de experiencias pasadas. El Instituto de la Industria de la Construcción publicó una lista de verificación de riesgos de 100 ítems que proporciona ejemplos y áreas de riesgos de proyectos Ninguna lista de verificación de riesgos incluirá todos los riesgos potenciales. El valor de una lista de verificación es el estímulo de la discusión y el pensamiento sobre los riesgos potenciales en un proyecto.

    El equipo del proyecto analiza los riesgos identificados y estima la probabilidad de que ocurran los riesgos. Luego, el equipo estima el impacto potencial en los objetivos del proyecto si ocurre el evento. El resultado de este proceso es una lista priorizada de riesgos estimados del proyecto con un valor que representa la probabilidad de ocurrencia y el impacto potencial en el proyecto.

    Luego, el equipo del proyecto desarrolla un plan de mitigación de riesgos que reduce la probabilidad de que ocurra un evento o reduce el impacto en el proyecto si ocurre el evento. El plan de gestión de riesgos se integra en el plan de ejecución del proyecto, y las actividades de mitigación se asignan al miembro del equipo del proyecto correspondiente. La probabilidad de que ocurran todos los eventos potenciales identificados en el análisis de riesgo es extremadamente rara. La probabilidad de que sucedan uno o más eventos es alta.

    El plan de riesgo del proyecto refleja el perfil de riesgo del proyecto y equilibra la inversión de la mitigación con el beneficio para el proyecto. Uno de los enfoques más comunes de mitigación de riesgos es el uso de contingencia. Contingencia son fondos reservados por el equipo del proyecto para atender imprevistos. Los proyectos con un perfil de alto riesgo suelen tener un gran presupuesto de contingencia. Si el equipo sabe qué actividades tienen el mayor riesgo, la contingencia se puede asignar a las actividades con mayor riesgo. Cuando los riesgos son menos identificables para actividades específicas, la contingencia se identifica en una partida separada. El plan incluye revisiones periódicas del plan de riesgo durante la vida del proyecto. La revisión de riesgos evalúa la efectividad del plan actual y explora posibles riesgos no identificados en sesiones anteriores.

    Adquisiciones de Proyectos

    El esfuerzo de adquisición de proyectos varía ampliamente y depende del tipo de proyecto. A menudo, la organización cliente brindará servicios de compras en proyectos menos complejos. En este caso, el equipo del proyecto identifica los materiales, equipos y suministros que necesita el proyecto y proporciona especificaciones del producto y un cronograma de entrega detallado. Cuando el departamento de adquisiciones de la organización matriz proporciona servicios de adquisiciones, un enlace del proyecto puede ayudar al equipo de adquisiciones a comprender mejor los requisitos únicos del proyecto y los elementos críticos o urgentes del cronograma del proyecto.

    En proyectos más grandes y complejos, el personal se dedica a adquirir y administrar los equipos, suministros y materiales que necesita el proyecto. Debido a la naturaleza temporal de los proyectos, los equipos, insumos y materiales se adquieren como parte del producto del proyecto o para la ejecución del proyecto. Por ejemplo, los ladrillos adquiridos para un proyecto de construcción serían adquiridos para el producto del proyecto, y la mezcladora de mortero sería equipo adquirido para la ejecución de los trabajos del proyecto. Al término del proyecto, los equipos comprados o rentados para la ejecución de la obra del proyecto se venden, se devuelven a las organizaciones de renta, o se enajenan de alguna otra manera.

    Los proyectos más complejos suelen procurarse a través de diferentes métodos de adquisición y gestión. Las materias primas son productos comunes que se compran en función de la oferta más baja. Los productos básicos incluyen artículos como concreto para proyectos de construcción, suministros de oficina o incluso equipos de laboratorio para un proyecto de investigación. El segundo tipo de compras incluye los productos que se especifican para el proyecto. Los proveedores que pueden producir estos productos ofertan por un contrato. La adjudicación de un contrato puede incluir el precio, la capacidad de cumplir con el cronograma del proyecto, el ajuste para el propósito del producto y otras consideraciones importantes para el proyecto. La fabricación de un horno para una nueva acería sería proporcionada por un proveedor del proyecto. Otro ejemplo es el equipo especialmente diseñado y construido para un proyecto de investigación. El desempeño de estos proveedores se convierte en partes importantes del proyecto, y el gerente del proyecto asigna recursos para coordinar el trabajo y el cronograma del proveedor. El tercer enfoque de adquisiciones es el desarrollo de uno o más socios. Una firma de diseño que recibe el contrato de diseño para una gran parte de la acería y una firma de investigación que está realizando subpartes críticas de la investigación son ejemplos de posibles socios del proyecto. Un socio contribuye y se integra en el plan de ejecución. Los socios se desempeñan mejor cuando comparten la visión de éxito del proyecto y se invierten emocionalmente en el proyecto. El equipo de gestión del proyecto construye e implementa un plan de adquisiciones del proyecto que reconoce el enfoque de adquisiciones más eficiente y efectivo para apoyar el cronograma y los objetivos del proyecto.

    Gestión de partes interesadas del proyecto

    Las personas y las organizaciones pueden tener muchas relaciones diferentes con el proyecto. Más comúnmente, estas relaciones se pueden agrupar en aquellos que serán impactados por el proyecto y aquellos que pueden impactar en el proyecto.

    Un gerente de proyecto exitoso identificará a las partes interesadas al principio del proyecto. Para cada stakeholder, es importante identificar lo que quiere o necesita y qué influencia o poder tienen sobre el proyecto. Con base en esta información, se puede identificar la necesidad de comunicarse con el grupo de stakeholders o stakeholders, seguido de la creación de un plan de gestión de stakeholders. Se utiliza un registro de partes interesadas para identificar y rastrear las interacciones entre el proyecto y cada uno de los grupos de interés. Este registro debe actualizarse periódicamente, ya que pueden surgir nuevos actores en cualquier momento, y las necesidades y niveles de interés de un determinado actor pueden cambiar a lo largo del curso del proyecto.

    Cuadro 4.1 Registro de partes interesadas
    Área de Conocimiento Iniciando Planeación Ejecutando Monitoreo y Control Clausura
    Gestión de Integración de Proyectos Desarrollar la Carta del Proyecto Desarrollar Plan de Gestión de Proyectos
    • Monitorear y controlar el trabajo del proyecto
    • Realizar control de cambio integrado
     
    Cerrar proyecto o fase
    Gestión del alcance del proyecto
    • Gestión del alcance del plan
    • Requerimientos de recolección
    • Definir alcance
    • Crear EDT
     
    • Validar alcance
    • Alcance de control
     
    Gestión del tiempo del proyecto
    • Gestión de horarios del plan
    • Definir actividades
    • Secuencia de actividades
    • Estimar recursos de actividad
    • Estimar la duración de la actividad
    • Desarrollar horario
     
    Horario de control
    Gestión de Costos de Proyectos
    • Planificar la gestión de costos
    • Estimar costos
    • Determinar presupuesto
     
    Control de costos
    Gestión de Calidad de Proyectos Plan de gestión de la calidad Realizar aseguramiento de la calidad Control de calidad

    Resumen del desarrollo de Scrum

    “Scrum” es otra metodología formal de gestión de proyectos/desarrollo de productos y parte de la gestión ágil de proyectos. Scrum es un término del rugby (scrimmage) que significa una forma de reiniciar un juego. Es como reiniciar los esfuerzos del proyecto cada X semanas. Se basa en la idea de que realmente no sabes cómo planificar todo el proyecto por adelantado, así que comienzas y construyes datos empíricos, y luego vuelves a planificar e iterar a partir de ahí.

    Scrum utiliza sprints secuenciales para el desarrollo. Los sprints son como pequeñas fases de proyecto (idealmente de dos a cuatro semanas). La idea es tomar un día para planificar lo que se puede hacer ahora, luego desarrollar lo que se planeó, y demostrarlo al final del sprint. Scrum utiliza una breve reunión diaria del equipo de desarrollo para verificar qué se hizo ayer, qué se planea para el día siguiente y qué, si algo, impide que los integrantes del equipo logren lo que se han comprometido. Al finalizar el sprint, lo que se ha demostrado puede entonces ser probado, y se inicia el siguiente ciclo de sprint.

    La metodología Scrum define varios roles principales. Ellos son:

    • Propietarios del producto: esencialmente el dueño del negocio del proyecto que conoce la industria, el mercado, los clientes y los objetivos comerciales del proyecto. El propietario del producto debe estar íntimamente involucrado con el proceso Scrum, especialmente en la planeación y las partes de demostración del sprint.
    • Scrum Master: algo así como un gestor de proyectos, pero no exactamente. Los deberes del Scrum Master son esencialmente eliminar las barreras que impiden el progreso del equipo de desarrollo, enseñar al propietario del producto cómo maximizar el retorno de la inversión (ROI) en términos de esfuerzo de desarrollo, facilitar la creatividad y empoderamiento del equipo, mejorar la productividad del equipo, mejorar prácticas y herramientas de ingeniería, organizar reuniones diarias de pie, realizar un seguimiento del progreso y garantizar la salud del equipo.
    • Equipo de desarrollo: autoorganizado (liderazgo ligero), grupo empoderado; participan en la planificación y estimación para cada sprint, hacen el desarrollo y demuestran los resultados al final del sprint. Se ha demostrado que el tamaño ideal para un equipo de desarrollo es de 7 +/- 2. El equipo de desarrollo puede dividirse en “teamlets” que “pululan” en historias de usuario, las cuales se crean en la sesión de planeación de sprint.

    Por lo general, la forma en que se desarrolla un producto es que hay un “quemador frontal” (que tiene historias/tareas para el sprint actual), un “backburner” (que tiene historias para el próximo sprint), y un “refrigerador” (que tiene historias para después, así como cambios de proceso). Se puede ver un producto como que se ha desglosado así: producto -> características -> historias -> tareas.

    A menudo, las estimaciones de esfuerzo se realizan usando “puntos de historia” (minúscula = 1 SP, pequeña = 2 SP, mediana = 4 SP, grande = 8 SP, grande = 16+ SP, desconocida =? SP) Las historias pueden ser de varios tipos. Las historias de usuario son muy comunes y son descripciones de lo que el usuario puede hacer y lo que sucede como resultado de diferentes acciones desde un punto de partida determinado. Otro tipo de historias son de estas áreas: análisis, desarrollo, QA, documentación, instalación, localización y capacitación.

    Las reuniones de planeación para cada sprint requieren la participación del propietario del producto, el Scrum Master y el equipo de desarrollo. En la reunión de planeación, establecieron las metas para el próximo sprint y seleccionan un subconjunto del backlog del producto (historias propuestas) para trabajar. El equipo de desarrollo descompone historias en tareas y las estima. El equipo de desarrollo y el propietario del producto hacen las negociaciones finales para determinar el retraso para el siguiente sprint.

    La metodología Scrum utiliza métricas para ayudar con la planeación futura y el seguimiento del progreso; por ejemplo, “quemar” —el número de horas que quedan en el sprint versus el tiempo en días; “velocidad” — esencialmente, la cantidad de esfuerzo que el equipo invierte. (Después de aproximadamente tres sprints con el mismo equipo, uno puede tener una idea de lo que el equipo puede hacer en el futuro).

    Algunas advertencias sobre el uso de la metodología Scrum: 1) Necesitas desarrolladores comprometidos y maduros; 2) Aún necesitas hacer una definición de requisitos importantes, algún análisis, definición de arquitectura y definición de roles y términos por adelantado o temprano; 3) Necesitas compromiso de la empresa y el propietario del producto; y 4) Es lo mejor para productos que requieren nuevos lanzamientos o actualizaciones frecuentes, y menos efectivos para productos grandes y totalmente nuevos que no permitirán actualizaciones frecuentes una vez que se lancen.

    La Oficina de Gestión de Proyectos

    Muchas organizaciones grandes e incluso medianas han creado un departamento para supervisar y apoyar proyectos en toda la organización. Esto es un intento de reducir el alto número de proyectos fallidos (ver el capítulo Descripción general de la gestión de proyectos). Estas oficinas suelen llamarse la oficina de gestión de proyectos o PMO.

    El PMO puede ser el hogar de todos los gerentes de proyectos de una organización, o simplemente puede ser un recurso para todos los gerentes de proyecto, que reportan a sus áreas de línea.

    Los objetivos típicos de una PMO son:

    • Ayudar a asegurar que los proyectos estén alineados con los objetivos organizacionales
    • Proporcionar plantillas y procedimientos para su uso por parte de los gerentes de proyecto
    • Brindar capacitación y tutoría
    • Brindar facilitación
    • Manténgase al tanto de las últimas tendencias en gestión de proyectos
    • Servir como repositorio de informes de proyectos y lecciones aprendidas

    La existencia y el papel de las OMP tiende a ser algo fluida. Si se crea una PMO y no se experimenta un mayor éxito en proyectos organizacionales, la PMO corre el riesgo de ser desbandada como medida de ahorro de costos. Si una organización en la que eres gerente de proyecto o miembro del equipo de proyectos tiene una PMO, trata de hacer un buen uso de los recursos disponibles. Si estás empleado como persona de recursos en una PMO, recuerda que tu rol no es interponerte en el camino y crear trámites administrativos, sino habilitar y mejorar el éxito de los gerentes de proyectos y proyectos dentro de la organización.

    Atribuciones de texto

    Este capítulo de Project Management es un derivado de los siguientes textos:

    Atribuciones de medios


    This page titled 1.4: Marco para la Gestión de Proyectos is shared under a CC BY-SA license and was authored, remixed, and/or curated by Adrienne Watt (BCCampus) .