Prefacio El Marco de la Administración de Proyectos



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

Actualizaciones a la estructura de desglose de trabajo. Al usar el WBS para identificar que actividades son necesarias, el equipo del proyecto puede identificar entregas faltantes o puede determinar que la descripción de la entrega puede necesitar clarificación o corrección. Tales actualizaciones deben ser reflejadas en el WBS y documentos relacionados tales como estimativos de costos. Estas actualizaciones se llaman muchas veces refinamientos y son muy probables cuando el proyecto involucra tecnología nueva o tecnología que no ha sido ensayada.

Secuencia de Actividades

La secuencia de las actividades involucra identificar y documentar las dependencias entre actividades. Las actividades deben de ser secuenciadas de manera precisa de tal manera que soporten luego el desarrollo de una programación realista y alcanzable. El secuenciamiento puede ser ejecutado con la ayuda de un computador (e.g., usando software de administración de proyectos) o con técnicas manuales. Las técnicas manuales son muchas veces más efectivas en proyectos pequeños o en las fases tempranas de proyectos grandes cuando hay poco detalle disponible. Las técnicas manuales o automatizadas también pueden ser usadas en combinación.





6,2 Entradas a la Secuencia de Actividades

  1. Lista de actividades. La lista de actividades se describe en la sección 6.1.3.1.

  2. Descripción del producto. La descripción del producto se discute en la Sección 5.1.1.1. las características del producto muchas veces afectan la secuencia de actividades (e.g., el layout físico de una planta a construirse, interfaces de subsistemas en un proyecto de software). Mientras que estos efectos son muchas veces aparentes en las listas de actividades, la descripción del producto deberá ser revisada para asegurar precisión.

  3. Dependencias mandatorias. Las dependencias mandatorias son aquellas que son inherentes a la naturaleza del trabajo que se ejecuta. Muchas veces involucran limitaciones físicas (en un proyecto de construcción es imposible erigir la superestructura hasta que se haya construido las fundaciones; en un proyecto electrónico, un prototipo deberá ser construido antes de que se pueda ensayar). Las dependencias mandatorias también se llaman lógica dura.

  4. Dependencias discrecionales. Las dependencias discrecionales son aquellas que son definidas por el equipo de administración del proyecto. Deberán ser usadas con cuidado (y totalmente documentadas) ya que estas pueden limitar opciones posteriores de programación. Las dependencias discrecionales se definen usualmente basadas en el conocimiento de:

    • "Las mejores prácticas" dentro de un área de aplicación específica.

    • De algún aspecto inusual del proyecto donde una secuencia específica es deseada aunque hayan otras secuencias igualmente aceptables.

Las dependencias discrecionales también se pueden llamar lógica preferida, lógica preferencial, o lógica blanda.

  1. Dependencias externas. Las dependencias externas son aquellas que involucran una relación entre actividades del proyecto y actividades fuera de este. Por ejemplo, las actividades de ensayo en un proyecto de software pueden depender de hardware de una fuente externa, o paneles de discusión ambiental pueden ser requeridos antes de que pueda empezar la construcción de un proyecto.

  2. Restricciones. Las restricciones se describen en la Sección 6.1.1.4.

  3. Suposiciones. Las suposiciones se describen en la Sección 6.1.1.5.

      1. Técnicas y Herramientas para la Secuencia de Actividades.

  1. Método de diagrama de precedencia (PDM). Este es un método de construir una red de diagrama de proyecto usando nodos para representar las actividades y conectándolos con flechas que muestran las dependencias (véase la Sección 6.2.3.1.). La Figura 6-2 muestra un diagrama de red de proyectos sencilla usando PDM. Esta técnica también se llama actividad - sobre - nodo (activity - on - node, AON) y es el método usado por la mayoría de paquetes de software de administración de proyectos. PDM puede ser ejecutado de manera manual o en el computador.

Este incluye cuatro tipos de dependencias o de relaciones de precedencia:

    • Finalización- a - comienzo - la actividad "de" debe terminar antes de que la actividad "a" pueda comenzar.

    • Finalización – a- finalización - la actividad "de" debe terminar antes de que la actividad "a" pueda finalizar.

    • Comienzo- a- comienzo- la actividad "de" debe comenzar antes de que pueda comenzar la actividad "a".

    • Comienzo- a- finalización- la actividad "de" debe comenzar antes de que la actividad "a" pueda finalizar.

En PDM, la relación finalización – a - comienzo es el tipo de relación lógica más comúnmente usada. Las relaciones comienzo – a - final son raramente usadas, y típicamente solamente por ingenieros programadores profesionales. Usar relaciones comienzo a comienzo, finalización – a - finalización o comienzo a finalización con software de administración de proyectos, puede producir resultados inesperados ya que este tipo de relaciones no han sido implementadas de manera consistente.

  1. Método de diagramación con flechas. (Arrow diagramming method ADM). Este es un método para construir diagramas de red usando flechas para representar las actividades y conectándolas con nodos para mostrar las dependencias (véase también la Sección 6.2.3.1.). La Figura 6-3. muestra un diagrama de red de proyecto simple usando ADM. Esta técnica también se llama actividad— sobre — flecha (activity - on – arrow, AOA) y, aunque de menos uso que el PDM, es todavía la técnica preferida en algunas áreas de aplicación. ADM utiliza únicamente dependencias finalización—a—comienzo y puede requerir el uso de actividades ficticias para poder definir todas las relaciones lógicas de manera correcta. ADM puede ser ejecutado de manera manual o sistematizada.



  1. Método de diagramación condicional. Las técnicas de diagramación tales como: GERT (técnica de evaluación y repaso gráfica (Graphical Evaluation and Review Techique)) y modelos de Sistemas Dinámicos permiten el uso de actividades no secuenciales tales como loops (e.g., un ensayo que se debe repetir más de una vez) o ramales condicionales (e.g., una actualización de diseño que solo se necesita si la inspección detecta errores). Las técnicas de PDM y ADM no permiten el uso de loops o de ramales condicionales o probabilísticas.

  2. Patrones de red. Redes standarizadas pueden ser usadas para acelerar la preparación de diagramas de red de proyectos. Estas pueden incluir un proyecto entero o solamente una porción de este. Estas porciones de redes se conocen como "subnets" o "fragnets". Las subnets son especialmente útiles cuando un proyecto incluye detalles idénticos o casi idénticos tales como los pisos en una rasca cielos o ensayos clínicos en un proyecto de investigación farmacéutica, o módulos de programación en un proyecto de software.

      1. Salidas de la Secuencia de Actividades

  1. Diagrama de red del proyecto. Un diagrama de red del proyecto es una figura esquemática de las actividades del proyecto y sus relaciones lógicas (dependencias). La Figura 6-2 y 6-3 ilustran dos métodos diferentes para dibujar un diagrama de red de proyecto. Un diagrama de red de proyecto puede ser producida manualmente o por computador. Puede incluir los detalles completos de un proyecto o puede tener una o más actividades totalizadoras (hamacas). El diagrama deberá estar acompañado de una descripción que resuma y describa la lógica usada para las secuencias de las actividades. Cualquier secuencia fuera de lo usual deberá estar plenamente descrito.

El diagrama de red de proyecto muchas veces se llama incorrectamente diagrama PERT (técnica de evaluación y repaso de programa (Program Evaluation and Review Technique)). Un diagrama Pert es un tipo de diagrama de red proyectos que se usa muy poco hoy en día.

  1. Actualización a la lista de actividades. De la misma manera en que el proceso de definición de actividades puede generar actualizaciones al WBS, la preparación de la red de diagrama de proyecto puede revelar instancias en las que una actividad deberá ser dividida o de otra manera redefinida de manera que se pueda diagramar la relación de lógica correctas.

    1. Estimación de la Duración de las Actividades

La estimación de la duración de las actividades involucra estimar el número de períodos de trabajo que más probablemente se necesitara para completar cada actividad identificada. La persona o grupo del equipo del proyecto que este más familiarizado con la naturaleza de una actividad específica deberá estimar o al menos aprobar la duración de la actividad.

Estimar el número de períodos de trabajos requeridos para completar una actividad muchas veces requerirá considerar el tiempo transcurrido también. Por ejemplo, si "curado de concreto" requiere cuatro días de tiempo, este puede requerir de dos a cuatro períodos basado en (a) en que día de la semana comienza y en (b) si los días del fin de semana son tratados como períodos de trabajo o no. La mayoría de los programas computarizados de programación trataran el problema automáticamente.



La duración completa del proyecto también puede ser estimada usando herramientas y técnicas aquí presentadas, pero es calculada de manera apropiada como la salida del desarrollo de la programación (como se describe en la Sección 6.4).



      1. Entradas a la Estimación de la Duración de las Actividades

  1. Lista de actividades . La lista de actividades se describe en la Sección 6.1.3.1.

  2. Restricciones. Las restricciones se describen en la Sección 6.1.1.4.

  3. Suposiciones. Las suposiciones se describen en la Sección 6.1.1.5.

  4. Requerimientos de recursos. Los requerimientos de recursos se describen en la Sección 7.1.3.1. La duración de la mayoría de las actividades se verá influenciada significativamente por los recursos asignada a ella. Por ejemplo, dos personas trabajando juntas serán capaces de completar una actividad de diseño en la mitad del tiempo que le tomaría a cada uno individualmente realizar la tarea, mientras que una persona trabajando medio tiempo en la actividad tomará generalmente el doble del tiempo que la misma persona trabajando tiempo completo.

  5. Capacidades de recursos. La evaluación de la mayoría de las actividades se verá influenciada significativamente por las capacidades de los recursos humanos y materiales asignados a ella. Por ejemplo, si dos miembros del staff son asignados tiempo completo, se podrá esperar que el miembro senior completa la tarea en menos tiempo, que le tomará al miembro junior terminar la tarea.

  6. Información histórica. La información histórica de la duración más probable de muchas categorías de actividades, está muchas veces disponible de una o de más de las siguientes fuentes:

    • Archivos de proyecto— una o más de las organizaciones involucradas en el proyecto puede mantener récords de resultados de proyectos previos que sean lo suficientemente detallados para ayudar en el desarrollo de los estimativos de duración. En algunas áreas de aplicación, individuos del equipo de trabajo pueden mantener tales records.

    • Bases de datos de estimación comerciales — mucha información histórica está disponible comercialmente. Estas bases de datos tienden a ser especialmente útiles cuando las duraciones no son función del contenido de trabajo real (e.g., cuando tiempo se demora el concreto para curar; generalmente cuando se demora un agente gubernamental para responder a ciertas requisiciones).

    • Conocimiento del equipo de proyecto — los miembros individuales del equipo del proyecto pueden recordar estimativos actuales o previos. Mientras que tales recolecciones puedan ser útiles, son generalmente menos fiables que resultados documentados.

      1. Herramientas y Técnicas para la Estimación de la Duración de las Actividades

  1. Opinión experta. :La opinión experta esta descrita en la Sección 5.1.2.2. Las duraciones son muchas veces difíciles de estimar porque hay un número de factores que las pueden influenciar (e.g., niveles de recursos, productividad de los recursos). La opinión experta guiada por información histórica deberá ser usada cuando sea posible. Si tal experiencia no esta disponible, los estimativos son inherentemente inciertos y riesgosos (véase Capítulo 11, Administración de Riesgo del Proyecto).

  2. Estimación análoga. La estimación análoga, también llamada estimación de arriba—hacia abajo, precisa usar duraciones reales de una actividad previa y similar como base para la estimación de la duración futura de una actividad. Es usada frecuentemente para estimar la duración de proyectos cuando hay una cantidad limitada de proyecto (e.g., como en sus fases iniciales) la estimación análoga es una forma de opinión experta (tal como se describe en la Sección 6.3.2.1.)

La estimación análoga es más fiable cuando (a) la actividad previa es similar de hecho y no solo en apariencia, y (b) cuando los individuos preparando los estimativos tienen la experiencia necesaria.

  1. Simulación. La simulación involucra calcular múltiples duraciones con diferentes juegos de suposiciones. La más común es Análisis de Monte Carlo en la que una distribución de posibles resultados es definida para cada actividad y es a su vez usada para calcular la distribución de posibles resultados para todo el proyecto (véase también la Sección 11.2.2.3., Simulación de la Programación).

      1. Salidas de la Estimación de la Duración de las Actividades

  1. Estimación de la duración de la actividad. La estimación de la duración de la actividad son evaluaciones cuantitativas del número de períodos de trabajo más probable que se requerirá para completar una actividad.

La estimación de la duración de las actividades siempre deberá incluir alguna indicación del rango de posibles resultados. Por ejemplo:

    • 2 semanas ±2 días para indicar que la actividad tomará por lo menos 8 días pero no más de 12.

    • 15% de probabilidad de exceder 3 semanas para indicar una alta probabilidad - 85% -de que la actividad tomará 3 semanas o menos.

El capítulo 11 sobre Administración de Riesgo del Proyecto incluye una discusión más detallada acerca de la estimación de la incertidumbre.

  1. Bases de estimación. Las suposiciones hechas en el desarrollo de los estimativos deberán estar documentados.

  2. Actualizaciones a la lista de actividades. Las actualizaciones a la lista de actividades se describen en la Sección 6.2.3.2.

    1. Desarrollo de la Programación

El desarrollo de la programación requiere determinar fechas de comienzo y finalización para las actividades del proyecto. Si la fechas de comienzo y finalización no son realistas, el proyecto tendrá pocas probabilidades de terminar como programar. El proceso de desarrollo de la programación, muchas veces tendrá que ser iterante (al mismo tiempo con los procesos que proveen entradas, especialmente la estimación de las duraciones y de costos) antes de la determinación de la programación del proyecto.



6.4.1 Entradas al Desarrollo de la Programación

  1. Diagrama de red del proyecto. El diagrama de red del proyecto se describe en la Sección 6.2.3.1.

  2. Estimación de la duración de las actividades. La estimación de la duración de las actividades se describe en la Sección 6.3.3.1.

  3. Requerimientos de recursos. Los requerimientos de recursos se describen en la Sección 6.3.1.4.

  4. Descripción del pool de recursos. El conocimiento de que recursos estarán disponibles en que tiempos y en que patrones es necesario para el desarrollo de la programación. Por ejemplo, los recursos compartidos podrán ser especialmente difíciles de programar ya que su disponibilidad puede ser altamente variable.

El grado de detalle y el nivel de especificidad en la descripción del pool de recursos puede variar. Por ejemplo, para el desarrollar preliminar de la programación de un proyecto de consultoria, uno solo necesita saber que dos consultores estarán disponibles en un marco de tiempo específico. La programación final del mismo proyecto sin embargo, debe identificar que consultores específicos estarán disponibles.

  1. Calendarios. Los calendarios de proyecto y de recursos identifican períodos de tiempo donde es permitido trabajar. Los calendarios de proyecto afectan a todos los recursos (e.g., algunos proyectos solo trabajaran durante horas normales de negocio, mientras que otros trabajaran tres turnos diariamente). Los calendarios de recursos afectan a un recurso o categoría de recurso en particular (e.g., un miembro del equipo de proyecto puede estar de vacaciones o en un curso de capacitación, un contrato colectivo de trabajo puede limitar la labor de algunos empleados durante la semana).

  2. Restricciones. Las restricciones están descritas en la Sección 6.1.1.4. Existen dos categorías de importancia que deben ser consideradas durante el desarrollo de la programación del proyecto:

    • Fechas impuestas. La entrega de ciertos productos en una fecha especifica puede ser requerida por un patrocinador del proyecto, el cliente del proyecto, u otros factores externos (e.g., una ventana de mercadeo en un proyecto tecnológico, una fecha impuesta judicialmente en un proyecto de remediaron ambiental).

    • Eventos claves o hitos de importancia. La entrega de ciertos productos en una fecha especifica puede ser solicitada por un patrocinador del proyecto, el cliente de proyecto, u otros partidos interesados. Una vez programados, estas fechas se vuelven formales, y muchas veces sólo se pueden cambiar con gran dificultad.

  1. Suposiciones. Las suposiciones se describen en la Sección 6.1.1.5.

  2. Holguras y tiempos de espera. Cualquiera de las dependencias puede requerir de una holgura o tiempo de espera (lags y leads) para poder definir de manera correcta la relación (e.g., puede existir un retraso de dos semanas entre la compra de un equipo y su instalación para su uso).

6.4.2 Herramientas y Técnicas para el Desarrollo de la Programación

  1. Análisis matemático. El análisis matemático requiere calcular las fechas teóricas tempranas y tardías para todas las actividades sin tener en cuenta cualquier limitación del pool de recursos disponibles. Las fechas resultantes no son la programación, sino que mas bien indican los periodos de tiempo el los que las actividades se deberían programar dadas las limitaciones de recursos y de otros tipos conocidas. Las técnicas más comunes conocidas son:

    • Método de la Ruta Crítica (CPM)— calcula un solo juego determinístico de fechas tempranas y tardías de comienzo y finalización para cada actividad, basada en una lógica de red secuencial y solo una duración. El foco de CPM es calcular la flotación para poder determinar que actividades tienen la menor flexibilidad de programación. Los algoritmos inherentes a CPM son muchas veces usados en otros tipos de análisis matemáticos.

    • Método de Evaluación y Revisión Gráfica (GERT)— permite el tratamiento probabilístico de tanto la red de lógica como de la estimación de las duraciones de las actividades (i.e., algunas actividades pueden no ser ejecutadas, algunas pueden ser ejecutadas algunas veces, y otras pueden ser ejecutadas varias veces).

    • Técnica de Evaluación y Revisión de Programas (PERT)— usa lógica secuencial de red y una distribución por pesos para la duración de las actividades para calcular la duración del proyecto. Aunque existen algunas diferencias superficiales, PERT se diferencia de CPM en que PERT usa la media de la distribución (el valor esperado) en lugar del el valor más probable usado originalmente en CPM (véase la Figura 6-4). PERT se usa poco hoy día aunque muchas veces se usan estimados que se asemejan a PERT en cálculos de CPM.

  1. Compresión de duraciones. La compresión de duraciones es un caso especial de análisis matemático que busca maneras de acortar la duración del proyecto sin cambiar el alcance de este (e.g., cumplir fechas impuestas o metas de programación). La compresión de duraciones incluye técnicas tales como:



    • Crashing— el canje entre los costos y la programación son analizados para determinar el mayor grado de compresión a cambio de el menor aumento posible en los costos. El crashing no siempre produce alternativas viables y muchas veces resulta en costos incrementados.

    • Fast Tracking— es realizar actividades en paralelo que normalmente se ejecutarían en secuencia (e.g., comenzar a escribir código en un proyecto de software antes de que su diseño haya terminado, o comenzar la construcción de los cimientos para una planta de procesamiento de petróleos antes de que sus ingenierías lleguen al 25%). El fast tracking muchas veces resulta en trabajos que hay que repetir, y aumenta de manera desproporcionada el riesgo asociado con el proyecto.

  1. Simulaciones. Las simulaciones son descritas en la sección 6.3.2.3.

  2. Heurísticas de nivelación de recursos. El análisis matemático muchas veces produce una programación preliminar que requiere mas recursos durante ciertos periodos de tiempo de los que hay disponibles, o que requiere cambios en los niveles de recursos que no son manejables. Una heurística como "asignar recursos críticos escasos a actividades de la ruta critica primero" pueden ser aplicados para desarrollar una programación que refleje tales restricciones. La nivelación de recursos muchas veces resulta en una programación que es mas larga en duración que la programación preliminar. Esta técnica es a veces llamada el "método basado en recursos", especialmente cuando se implementa con optimización por computador.

La programación con base en restricciones de recursos es un caso especial de nivelación de recursos en donde la heurística involucrada es una limitación en la cantidad de recurso disponible.

  1. Software de administración de proyectos. El software de administración de proyectos es de uso común para asistir en el desarrollo de la programación del proyecto. Estos productos automatizan él calculo del análisis matemático y de la nivelación de recursos, y por lo tanto permiten una consideración rápida de las muchas alternativas de programación. También son de uso común para la impresión y presentación del desarrollo de la programación del proyecto.




1   2   3   4   5   6   7   8   9   10   ...   17


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

    Página principal