Gestión y control de proyectos informáticos. Estimación de recursos. Planificación temporal y organizativa. Seguimiento.

De MediaWiki
Ir a la navegación Ir a la búsqueda

Sumario

Introducción

Gestión y control de proyectos informáticos

Prince2

Prince2 proviene del acrónimo en inglés PRojects IN Controlled Environments (PRINCE), es decir, convertir proyectos que manejan una carga importante de variabilidad y de incertidumbre en entornos controlados. Prince2 esta perfectamente alineada con la norma ISO-21500 de Gestión de proyectos.

La aplicación de la metodología Prince2 va más allá del tipo de proyecto, pudiendo aplicarse en proyectos de toda índole, y por supuesto en el Desarrollo de software.

Más que un conjunto de buenas prácticas, Prince2 propone una metodología de gestión de proyectos que se plantea sean realizados considerando siete temas.

Estos temas deben ser revisado durante el ciclo de vida del proyecto y justificar en todo momento el proyecto como consecución de los beneficios esperados. Se plantean también 6 "aspectos" (metas de desempeño) , 7 principios y 7 procesos.

Temas

  • Describen aspectos de la gestión del proyecto. Éstas se deben aborda rcontinuamente
  • Debemos adaptarlos en función del tamaño, naturaleza y complejidad del proyecto.

Los siete temas son:

  • Business Case (o necesidad del negocio)
  • la Calidad
  • el Cambio
  • la estructura de roles del proyecto (Organización)
  • los Planes (Cuánto, Cómo, Cuando)
  • el Riesgo
  • el Progreso

Principios

La metodología que Prince2 propone se apoya en siete Principios, enriqueciendo no solo al proyecto en concreto, sino a toda la organización en la que se desarrolla. Son las obligaciones y buenas prácticas que determinan si el proyecto se está gestionando mediante metodología Prince2:

  1. Justificación comercial continua
    Se asegura de que hay un motivo justificable para iniciar el proyecto.
    La justificación se mantiene válida durante toda la vida del proyecto.
    Dicha justificación ha sido identificada, y aprobada.
  2. Aprender de la experiencia
    Se recogen las experiencias anteriores, las que se van obteniendo a lo largo de la ejecución del proyecto, así como las lecciones aprendidas al cierre del mismo.
  3. Roles y Responsabilidades definidos
    Asegurando que los intereses de los usuarios que van a usar el proyecto, los proveedores y el responsable del área de negocio están representados en la toma de decisiones.
  4. Gestión por Fases
    Un proyecto que sigue la metodología PRINCE2 se planifica, se supervisa y se controla fase a fase.
  5. Gestión por excepción
    Delegar la autoridad suficiente de un nivel de gestión al siguiente, dándole autonomía según unas tolerancias pautadas (de tiempo, coste, calidad, alcance, beneficio y/o riesgo) de manera que, de sobrepasar la tolerancia, se consulte al nivel superior como actuar.
  6. Orientación a productos
    Centra la atención en la definición y entrega de productos, es decir, un proyecto no son un conjunto de tareas a realizar, sino que entrega productos (que se elaboran tras la ejecución de las tareas que sean necesarias).
  7. Adaptación al entorno del proyecto
    Asegurando que la metodología PRINCE2 y los controles a aplicar se basen en el tamaño, complejidad, importancia, capacidad y nivel de riesgo del proyecto.

Procesos

Un proceso es un conjunto de actividades diseñadas para lograr un objetivo específico.

Dichos procesos van desde el pre-proyecto hasta la fase final de entrega de los productos, pasando por la fase de inicio y las fases de entrega necesarias, según el tipo de proyecto. Son:

  1. Puesta en Marcha (SU)
  2. Inicio de un Proyecto (IP)
  3. Dirección de un Proyecto (DP)
  4. Gestión de los Límites de Fase (SB)
  5. Control de una Fase (CS)
  6. Gestión de la Entrega de Productos (PD)
  7. Cierre de un proyecto (CP)
Los siete procesos de la metodología Prince2

Prince2 a través de los productos de gestión

Este enfoque aborda Prince2 siguiendo los diferentes productos de gestión que se generan en cada uno de los procesos. El siguiente diagrama muestra una versión simplificada de este enfoque (se puede ver aquí mayor detalle de los productos de gestión).

Prince2 a través de los productos de gestión
Prince2 no tiene por qué ser aun método de gestión "pesado". Los productos de gestión de Prince2 se mantienen cualquiera que sea el proyecto y pueden utilizarse como se describe en la guía oficial; pero también pueden ser modificados para adaptarse a cualquier proyecto, siguiendo el principio de PRINCE2 "adaptación al entorno de un proyecto".

PMBOK

La Guía de los fundamentos para la dirección de proyectos (del inglés A Guide to the Project Management Body of Knowledge o PMBOK por sus siglas) es un libro en el que se presentan estándares, pautas y normas para la gestión de proyectos. La última versión es la 6ª, publicada el 6 de septiembre de 2017

La Guía PMBOK identifica el subconjunto de fundamentos de gestión de proyectos que es "generalmente reconocido" como una "buena práctica". Con "generalmente reconocido" se trata de referir a los conocimientos y prácticas aplicables a la mayoría de los proyectos, la mayor parte del tiempo; en la que hay un consenso sobre su utilidad e importancia; mientras que "buena práctica" implica que hay un acuerdo general para la aplicación de los conocimientos, habilidades, herramientas y técnicas que pueden aumentar las posibilidades de éxito a lo largo de muchos proyectos.

Sin embargo, esto no significa que las tendencias de gestión de proyectos estén especificadas o incluidas en la guía. (Por ejemplo, el parámetro de arrastre de camino crítico, una metodología aplicable para la gestión de un proyecto, no está definida en sí en la guía PMBOK).

Contenido

La Guía PMBOK está basada en procesos, lo que significa que ésta describe el trabajo aplicado en los procesos en sí. Este enfoque es coherente, y muy similar, al mismo usado en otros estándares de gestión, por ejemplo ISO 9000 y CMMI. Los procesos se superponen e interactúan a lo largo de la realización de las fases del proyecto.

Los procesos están descritos en términos de:

  • Entradas (documentos, planes, diseños, etc.)
  • Herramientas y técnicas (mecanismos aplicados a las entradas)
  • Salidas (documentos, planes, diseños, etc.)

La guía del PMBOK describe en su 6ª edición 49 procesos de dirección de proyecto que clasifica en 10 áreas de conocimiento (Integración, Alcance, Tiempo, Costes, Calidad, Recursos, Comunicación, Riesgos, Adquisiciones e Interesados) y 5 grupos de procesos (Inicio, Planificación, Ejecución, Monitoreo y control y Cierre). Los procesos y su clasificación es la siguiente:


Grupos de Procesos de la Dirección de Proyectos, PMBOK 6 Ed. 2017
Área de conocimiento Inicio

(2)

Planificación

(24)

Ejecución

(10)

Monitoreo y Control

(12)

Cierre

(1)

Integración (7) 4.1 Desarrollar el acta de constitución del proyecto 4.2 Desarrollar el plan para la dirección del proyecto 4.3 Dirigir y gestionar el trabajo del proyecto

4.4 Gestionar el conocimiento del proyecto

4.5 Monitorear y controlar el trabajo del proyecto

4.6 Realizar el control integrado de cambios

4.7 Cerrar el proyecto o fase
Alcance (6)   5.1 Planificar la gestión de alcance

5.2 Recopilar requisitos

5.3 Definir alcance

5.4 Crear la EDT

  5.5 Validar alcance

5.6 Controlar el alcance

 
Cronograma

(6)

  6.1 Planificar la gestión del cronograma

6.2 Definir las actividades

6.3 Secuenciar las actividades

6.4 Estimar la duración de las actividades

6.5 Desarrollar el cronograma

  6.6

Controlar el cronograma

 
Costos (4)   7.1 Planificar la gestión de los costos

7.2 Estimar los costos

7.3 Determinar el presupuesto

  7.4

Controlar los costos

 
Calidad (3)   8.1 Planificar la gestión de la calidad 8.2 Gestionar la Calidad 8.3 Controlar calidad  
Recursos (6)   9.1 Planificar la gestión de recursos

9.2 Estimar los recursos de las actividades

9.3 Adquirir los recursos

9.4 Desarrollar el equipo

9.5 Dirigir al equipo

9.6 Controlar los recursos  
Comunicaciones

(3)

  10.1 Planificar la gestión de las comunicaciones 10.2 Gestionar las comunicaciones 10.3 Monitorear las comunicaciones  
Riesgos (6)   11.1 Planificar la gestión de riesgos

11.2 Identificar los riesgos

11.3 Realizar el análisis cualitativo de riesgos

11.4 Realizar el análisis cuantitativo de riesgos

11.5 Planificar la respuesta a los riesgos

11.6 Implementar la respuesta a los riesgos 11.7 Controlar los riesgos  
Adquisiciones

(4)

  12.1 Planificar la gestión de las adquisiciones 12.2 Efectuar las adquisiciones 12.3 Controlar las adquisiciones  
Interesados

(4)

13.1 Identificar a los interesados 13.2 Planificar el involucramiento de los interesados 13.3 Gestionar la participación de los interesados 13.4 Monitorear el involucramiento de los interesados  

Documentos adicionales

A pesar de que la Guía PMBOK ofrece directrices generales para la gestión de la mayoría de los proyectos la mayor parte del tiempo, existen 3 documentos que sirven como extensiones para la misma. En particular . es relevante para proyectos de tecnologías de información las "Software Extensions" (de la Guía PMBOK 6ta Ed.): .

Metodologías ágiles

Scrum

Resumido al extremo, Scrum:

  • Divide la organización en equipos pequeños, interdisciplinarios y auto-organizados.
  • Divide el trabajo en una lista de entregables pequeños y concretos. Ordena la lista por orden de prioridad y estima el esfuerzo relativo de cada elemento.
  • Divide el tiempo en iteraciones cortas de longitud fija (generalmente de 1 a 4 semanas), con código potencialmente entregable y demostrado después de cada iteración.
  • Optimiza el plan de entregas y actualiza las prioridades en colaboración con el cliente, basada en los conocimientos adquiridos mediante la inspección del entregable después de cada iteración.
  • Optimiza el proceso teniendo una retrospectiva después de cada iteración

Así en lugar de un grupo numeroso pasando mucho tiempo construyendo algo grande, tenemos un equipo menor pasando un tiempo más corto construyendo algo menor. Pero integrando con regularidad para ver el conjunto

  • Scrum divide tu organización equipos pequeños

  • Scrum divide el trabajo en una lista de entregables pequeños y concretos

  • Scrum divide el tiempo en iteraciones cortas (sprints)

  • Scrum optimiza el plan de entregas y actualiza las prioridades en colaboración con el cliente

  • Scrum optimiza el proceso teniendo una retrospectiva después de cada iteración

Kanban

Un tablero Kanban es un tablero en el cual vamos a tener una serie de tarjetas, cada una de ellas corresponderá a una tarea dentro de un proyecto software, y vamos a tener una serie de posiciones por las que las tarjetas se van a ir moviendo. Esto nos va a permitir con una gestión muy visual ver cómo evoluciona el proyecto.

Funciona del siguiente modo:

  • Visualiza el flujo de trabajo
    • Divide el trabajo en bloques, escribe cada elemento en una tarjeta y ponlo en el muro.
    • Utiliza columnas con nombre para ilustrar dónde está cada elemento en el flujo de trabajo.
  • Limita el WIP (Work in Progress, trabajo en curso) - asigna límites concretos a cuántos elementos pueden estar en progreso en cada estado del flujo de trabajo.
  • Mide el lead time (tiempo medio para completar un elemento, a veces llamado "tiempo de ciclo"), optimiza el proceso para que el lead time sea tan pequeño y predecible como sea posible.

Este sistema fue inventado por el señor Taiichi Ohno, de Toyota.

  • Un tablero Kanban

  • Otro tablero Kanban

  • Se debe limitar el WIP

  • Medición del Lead Time

Similitudes y diferencias

Se puede generalizar que tanto Scrum como Kanban están bien alineados con los valores y principios del Manifiesto Ágil:

  • Son sistemas de planificación tipo "Pull", principio de gestión de inventario Just In Time (JIT) propio de Lean.
  • Ee basan en procesos de optimización continuos y empíricos, que se corresponden con el principio Kaizen de Lean.
  • Dan más importancia a la respuesta al cambio que al seguimiento de un plan..
  • Establecen límites WIP.
  • Tienen como objetivo la entrega temprana y frecuente de software.
  • Trabajan con equipos auto-organizados.
  • Necesitan la división del trabajo en parte.
  • En ambos la visibilidad del proceso es la base de su mejora.

  • Kanban y Scrum son empíricos

Algunas diferenciar entre Kanban y lo que es la metodología Scrum en sí son:

  1. En Scrum existen los roles de Scrum Master, de Product Owner y del equipo, mientras que Kanban no existen roles.
  2. En Scrum se trabaja con iteraciones de tiempo fijo, con unos ciclos fijos que se denominan Sprints, mientras que en Kanban tenemos un trabajo continuo y no tenemos esas interacciones o esos ciclos durante el desarrollo.
  3. Scrum limita el WIP (Work In Progress o número de tareas que se pueden tener en paralelo en una de las posiciones del tablero) por iteración, mientras que Kanban limitar ese WIP por el estado del flujo de trabajo.
  4. Mientras que Scrum exige equipos multidisciplinares, para que todos los miembros del equipo puedan realizar varias tareas y sea todo más más ágil, en Kanban se permiten los equipos formados por especialistas. En este caso podemos tener algún problema a la hora de gestionar esos equipos, pero existen una serie de normas o de prácticas para llevar a cabo para solucionarlo.
  5. En Scrum no se permiten cambiar las tareas del Sprint, es decir, una vez que la tarea asignada al mismo no puede ser movida, en todo caso lo que se permite es modificar la fecha de entrega del Sprint, pero no esa tarea. En Kanban, por el contrario, se puede modificar la tarea hasta que entra en flujo, hasta ese momento podemos modificar la tarea.
  6. En Scrum la pila del producto, es decir, el conjunto de tareas que tenemos que realizar durante el Sprint, tiene que tener al menos el tamaño de un Sprint, ya que, lógicamente, no podemos tener menos de un Sprint. En Kanban, al tener un ritmo de trabajo continuo, lo que se hace es ir arrastrando las nuevas tareas por el panel hasta que lleguen a su estado final y finalicen. Cualquier nuevo requisito del cliente será una nueva tarjeta o post-it que se añadirá al flujo de entrada y que seguirá su flujo normal hasta la salida.
  7. En Scrum se mide todo lo que sea necesario, se miden historias, es decir, cuánto nos va a llevar realizar cada historia de usuario, se mide cuánto tiempo o esfuerzo nos va a llevar realizar cada una de las tareas y se mide también la velocidad del equipo, que es la cantidad de trabajo que hemos realizado dividido por la cantidad de tiempo. En Kanban, como ya tenemos una cierta habilidad de la metodología, no se miden ni tareas ni velocidad.
  8. En Scrum se necesita una pila del producto priorizada, porque como el desarrollo completo lo vamos a dividir en distintos Sprints, la necesitamos para que los primeros Sprints se encarguen de realizar las tareas de mayor prioridad. Con lo que vamos a conseguir llevar valor al cliente de una manera mucho más rápida y las tareas con menor prioridad serán realizando en los Sprints posteriores. Esta priorización la hará el Product Owner. En Kanban la historia o tarea es arrastrada directamente desde el cliente, por lo cual no necesita esa priorización.
  9. En Scrum se tienen una serie de reuniones y se utilizan una serie de gráficos, como el burn down, en el que podemos ver el avance del proyecto, y el burn up, que sirve para medir la velocidad del equipo. En Kanban no se considera ni ese tipo de reuniones ni de gráficos.
  10. En Scrum los tableros se van a resetear al final de cada Sprint, es decir, conforme vamos finalizando el mismo, el tablero queda vacío y comenzamos de nuevo añadir nueva nuevas historias de usuario, las siguientes en prioridad. En Kanban, como vamos a tener un flujo de entrada-salida, conforme las tarjetas van pasando por cada uno de los estados hasta llegar al estado final, cuando llegan a ese estado salen del tablero y se archivan, vamos a tener un flujo continuo.

  • Kanban es menos prescriptivo

Estimación de recursos

La estimación de recursos consiste en la planificación y garantía de la disponibilidad de los mismos para asegurar el buen desarrollo y éxito de un proyecto . La gestión de los recursos disponibles es esencial para cualquier proyecto y debe tenerse en cuenta incluso antes de que el mismo comience.

La gestión de las cantidades de recursos necesarios, así como su optimización, son dos de los factores clave para cumplir con la entrega de un proyecto.

Cómo estimar costos de un proyecto

La estimación de los recursos está anclada a la gestión de un proyecto en el sentido más amplio, pues incluye diferentes aspectos relacionados con el proceso, tales como:

  • la proyección de la duración y coste de las actividades (presupuesto provisional),
  • la estructura de desglose de los recursos identificados por categorías (humanos, materiales, etc.),
  • la asignación de recursos para cada actividad (según los perfiles y habilidades).

Seguimiento de los recursos

Para evaluar una situación y tomar las decisiones correctas, debes implementar Indicadores Clave de Desempeño (KPI). Estos te permiten hacer una comparación entre lo estimado y lo realmente ejecutado. Por ejemplo, para los siguientes recursos:

  • Recursos humanos -> ¿cuán productivos son los recursos? Ejemplo de cálculo: número de días/hombre asignados a una tarea, multiplicado por el porcentaje de finalización de esa tarea.
  • Recursos materiales -> ¿cuál es la disponibilidad o la capacidad de ese equipo? Ejemplo de cálculo: número de horas de trabajo previstas en un equipo, comparado con el número de horas disponibles de este último = carga del equipo.
  • Recursos financieros -> ¿cuál es el costo actual de mi proyecto? ¿está dentro del presupuesto asignado? Ejemplo de cálculo: suma de todos los gastos dedicados al proyecto hasta el tiempo “t”.
  • Recursos de tiempo -> ¿van las actividades del proyecto en el plazo estimado? ¿va el proyecto ser entregado a tiempo? Ejemplo de cáulculo: cálculo de la holgura total del proyecto
Tipos de recursos en la gestión de proyectos

Gestión de riesgos

Los riesgos pueden afectar el buen funcionamiento del proyecto. Estrategias para riesgos negativos o amenazas son:

Evitar
Es una estrategia de respuesta a los riesgos según la cual el equipo del proyecto actúa para eliminar la amenaza o para proteger al proyecto de su impacto. Por lo general implica cambiar el plan para la dirección del proyecto, a fin de eliminar por completo la amenaza.
Transferir
Trasladar el impacto negativo del riesgo hacia un tercero.
Mitigar
Disminuir la probabilidad de ocurrencia y/o el impacto.
Aceptar
No cambiar el plan original. Una aceptación activa consiste en dejar establecida una política de cómo actuar en caso que ocurra el evento negativo.

Hay tres herramientas que nos pueden ayudar en esa gestión de riesgos:

Estimación con PMP

Para cada actividad del Proyecto, estimar los recursos de las actividades del Cronograma implica determinar las personas, equipos y/o materiales necesarios para llevarla a cabo. Qué cantidad de cada recurso se utilizará y cuándo estarán disponibles dichos recursos.

Previamente, debemos realizar una estimación de la necesidad de recursos y determinar la disponibilidad de los mismos. La duración de una actividad está normalmente condicionada al número de recursos disponibles para la realización de la misma, y el número mínimo de recursos necesarios para llevarla a cabo.

Este proceso está directamente relacionado con el proceso "7.2. Estimar el Coste de las Actividades" ya que la mayor parte de los costos del Proyecto quedan determinados por los recursos necesarios para llevarlo a cabo y su coste asociado.

6.4 Estimar los Recursos de las Actividades

Entradas

  • Plan de Gestión del Cronograma
  • Lista de Actividades con sus Atributos
  • Calendarios de recursos. La información sobre la disponibilidad potencial de recursos también se utiliza para estimar los recursos de las actividades. Además de cuándo pueden estar disponibles, esta información también incluye la consideración de otros aspectos, tales como las diversas habilidades, experiencia y capacidades requeridos para los recursos humanos. O por ejemplo, las ubicaciones geográficas de los que están disponibles.
  • Registro de Riesgos. Salida del proceso 11.2 Identificar los Riesgos. Determinados eventos asociados al riesgo pueden influir en la selección y disponibilidad de los recursos. Las actualizaciones del registro de riesgos se cuentan entre las actualizaciones de los documentos del proyecto.
  • Factores ambientales. Se refiere a la disponibilidad y habilidades de los recursos de la empresa.
  • Activos de los procesos de la Organización. Políticas y procedimientos de recursos humanos, relacionados con el alquiler y/o adquisición de equipos e información histórica relevante.

Herramientas y Técnicas

  • Juicio de expertos. Expertos con experiencia en planificación y estimación de recursos.
  • Análisis de alternativas. Uso alternativo de recursos con diferentes niveles de capacidad o habilidades, diferentes tamaños y tipología de maquinaria y decisiones de compra, alquiler o fabricación de recursos.
  • Datos de estimación publicados. Índices de producción y costes unitarios de recursos publicados periódicamente por empresas.
  • Estimación ascendente. Consiste en descomponer con mayor detalle, el trabajo necesario para realizar una actividad que no puede estimarse razonablemente, y estimar la necesidad de recursos de la descomposición, sumando luego esta necesidad para obtener un total de recursos necesarios en la actividad.
  • Software de Gestión de Proyectos. Proporciona soporte para planificar, organizar y gestionar los recursos.

Salidas

  • Requisitos de recursos de la actividad. La salida principal del proceso es una identificación y descripción de los tipos y las cantidades de recursos necesarios para cada actividad del cronograma de un paquete de trabajo. Estas asignaciones pueden sumarse para determinar los recursos estimados para cada paquete de trabajo de la EDT/WBS, por lo que el nivel de detalle de las asignaciones y requisitos de los recursos puede variar según el área de aplicación. La documentación de los requisitos de recursos de cada actividad puede incluir las bases para la estimación económica de cada asignación. Los supuestos para determinar qué tipos de recursos se necesitan. Su disponibilidad y qué cantidad va a ser necesario utilizar. En el proceso de desarrollo del Cronograma se determina cuándo se necesitará el concurso y disposición de dichos recursos.
  • Estructura de desglose de recursos. RBS (Resource Breakdown Structure). Consiste en una estructura jerárquica de recursos, identificados por categoría y tipo, sirve como base para determinar las necesidades de comunicación dentro del Proyecto.
  • Actualizaciones. Sobre todo, seguramente hay que actualizar la lista y atributos de las actividades y también los calendarios de recursos, la cantidad de cada recurso disponible en cada período temporal.

Planificación temporal y organizativa. Seguimiento

Diagrama de Gantt

El diagrama de Gantt es una herramienta gráfica cuyo objetivo es exponer el tiempo de dedicación previsto para diferentes tareas o actividades a lo largo de un tiempo total determinado. A pesar de esto, el diagrama de Gantt no indica las relaciones existentes entre actividades.

Para la planificación del desarrollo de proyectos complejos (superiores a 25 actividades) se requiere además el uso de técnicas basadas en redes de precedencia como CPM o los diagramas PERT. Estas redes relacionan las actividades de manera que se pueda visualizar el camino crítico del proyecto (es decir, la actividad más compleja o la que demandará más tiempo) y permiten reflejar una escala de tiempos para facilitar la asignación de recursos y la determinación del presupuesto. El diagrama de Gantt, con todo, sí resulta útil para establecer una relación básica entre tiempo y carga de trabajo.

En gestión de proyectos, el diagrama de Gantt muestra el origen y el final de las diferentes unidades mínimas de trabajo y los grupos de tareas (llamados summary elements en la imagen) o las dependencias entre unidades mínimas de trabajo (no mostradas en la imagen).

Desde su introducción, los diagramas de Gantt se han convertido en una herramienta básica en la gestión de proyectos de todo tipo, con la finalidad de representar las diferentes fases, tareas y actividades programadas como parte de un proyecto o para mostrar una línea de tiempo en las diferentes actividades, haciendo el método más eficiente.

Básicamente, como ya se mencionó, el diagrama está compuesto por un eje vertical donde se establecen las actividades que constituyen el trabajo que se va a ejecutar, y un eje horizontal que muestra en un calendario la duración de cada una de ellas.

Uso con herramientas informáticas

Se puede elaborar un diagrama de Gantt con una hoja de cálculo de una manera muy sencilla, marcando determinadas celdas para formar la representación de cada tarea. Existen macros que automatizan esta elaboración en MS Excel y Libre/OpenOffice Calc.

Sin embargo, existen herramientas de gestión de proyectos dedicadas a la planificación y seguimiento de tareas que utilizan el diagrama de Gantt como pantalla principal. Se introducen las tareas y sus procesos son capaces de producir una representación de dichas tareas en el tiempo en el formato del gráfico de Gantt. También existen herramientas de licencia libre y software gratis, capaces de llevar a cabo dicho tipo de operación.

Se deben valorar, por último, el uso de herramientas que usan una página web y el navegador para realizar el seguimiento de proyectos.

Software privativo

La herramienta más popular de uso comercial es el Microsoft Project.

Software libre

Diagrama de hitos

El Diagrama de hitos es una herramienta simple para la representación gráfica del desarrollo de un plan de proyecto. Consiste en una tabla que relaciona los hitos con la fecha de inicio y/o finalización de los mismos.

Esta técnica tiene como ventajas la simplicidad y la facilidad de preparación. Y como inconveniente impide reflejar las interrelaciones entre las diferentes actividades, generando incertidumbre.

El diagrama de hitos se utiliza para resumir calendarios de proyectos.

ADM - Método del diagrama de flechas

ADM o Método del Diagrama de Flechas es una técnica de red de proyecto donde las actividades se representan como flechas que indican las dependencias entre los nodos.

Su utilización está cayendo en desuso debido a las ventajas que tiene la representación de actividades mediante nodos, conocida como PDM: esto hizo que la mayoría de los sistemas de computación desarrollados en los últimos años usen esa representación.

Las ventajas de PDM frente a ADM son:

  • La construcción de la red es mucho más sencilla ya que no requiere actividades ficticias (dummies).
  • Su modificación es trivial, frente a las complicaciones que pueden aparecer en ADM.
  • Permite introducir demoras en las relaciones, que en ADM implicaría la introducción de una nueva actividad; incluso se pueden usar demoras negativas en el caso en que la sucesora pueda empezar antes de finalizar la precedente.
  • Se pueden usar cuatro tipos de precedencias:
    • Fin Comienzo: Para comenzar la actividad debe haberse completado su precedente.
    • Comienzo Comienzo: Para comenzar una actividad debe haber comenzado su precedente.
    • Fin Fin: Para finalizar una actividad debe haberse finalizado su precedente.
    • Comienzo Fin: Para finalizar una actividad debe haber comenzado su precedente.
En cada una pueden usarse además demoras.

PDM - Método del diagrama de precedencias

El método del diagrama de precedencias (en inglés, Precedence Diagramming Method o PDM) es una herramienta para la programación de actividades en la planeación de un proyecto. Es un método de construcción de un diagrama de red del cronograma del proyecto que utiliza cajas, denominados nodos, para representar las actividades y los conecta con flechas que muestran las dependencias.

PDM (Precedence Diagram Method) o Método del Diagrama de Precedencias es una técnica de red de proyecto enfocada en las precedencias de las actividades. También se conoce como el método actividad-en-nodo (en inglés, activity-on-node o AON).

CPM - Método de la ruta crítica

El método de la ruta crítica o del camino crítico es un algoritmo utilizado para el cálculo de tiempos y plazos en la planificación de proyectos.<ref>Plantilla:Cita libro</ref> Este sistema de cálculo conocido por sus siglas en inglés CPM (Critical Path Method), fue desarrollado en 1957 en los Estados Unidos de América, por un centro de investigación de operaciones para las firmas Dupont y Remington Rand, buscando el control y la optimización de los costos mediante la planificación y programación adecuadas de las actividades componentes del proyecto. Otro proyecto importante de esa época, el proyecto del misil "Polaris" originó en 1958 la creación de uno de los métodos de programación por camino crítico, conocido con el nombre de PERT (Program Evaluation and Review Technique).<ref>Plantilla:Cita libro</ref>

En administración y gestión de proyectos, una ruta crítica es la secuencia de los elementos terminales de la red de proyectos con la mayor duración entre ellos, determinando el tiempo más corto en el que es posible completar el proyecto. La duración de la ruta crítica determina la duración del proyecto entero. Cualquier retraso en un elemento de la ruta crítica afecta a la fecha de término planeada del proyecto, y se dice que no hay holgura en la ruta crítica.

Un proyecto puede tener varias rutas críticas paralelas. Una ruta paralela adicional a través de la red con la duración total cercana a la de la ruta crítica, aunque necesariamente menor, se llama ruta sub-crítica.

Originalmente, el método de la ruta crítica consideró solamente dependencias entre los elementos terminales. Un concepto relacionado es la cadena crítica, la cual agrega dependencias de recursos. Cada recurso depende del manejador en el momento donde la ruta crítica se presente.

A diferencia de la técnica de revisión y evaluación de programas (PERT), el método de la ruta crítica usa tiempos ciertos (reales). Sin embargo, la elaboración de un proyecto basándose en redes CPM y PERT son similares y consisten en:

  • Identificar todas las actividades que involucra el proyecto, lo que significa, determinar relaciones de precedencia, tiempos técnicos para cada una de las actividades.
  • Construir una red con base en nodos y actividades (o arcos, según el método más usado), que implican el proyecto.
  • Analizar los cálculos específicos, identificando la ruta crítica y las holguras de las actividades que componen el proyecto.

En términos prácticos, la ruta crítica se interpreta como la dimensión máxima que puede durar el proyecto y las diferencias con las otras rutas que no sean la crítica, se denominan tiempos de holgura.

PERT - Técnica de revisión y evaluación de programas

La Técnica de Revisión y Evaluación de Programas (o Proyectos) (del inglés PERT, Program Evaluation and Review Techniques) es una técnica estadística de la administración y gestión de proyectos que fue diseñada para analizar y representar las tareas involucradas en culminar un proyecto.

Inventado en 1957 por la Oficina de Proyectos Especiales de la Marina de Guerra del Departamento de Defensa de Estados Unidos como parte del proyecto Polaris de misil balístico móvil lanzado desde submarino. Este proyecto fue una respuesta directa a la crisis del Sputnik.

Archivo:Pert chart colored.svg
Diagrama de red PERT para un proyecto de siete meses con 6 actividades (A hasta F) y 5 nodos

PERT es básicamente un método para analizar las tareas involucradas en completar un proyecto dado, especialmente el tiempo para completar cada tarea, e identificar el tiempo mínimo necesario para completar el proyecto total.

Es un algoritmo diseñado para una eficiente planificación de proyectos, desde el comienzo hasta la final, el resultado de la aplicación de este algoritmo es un cronograma de tareas, que determina cuanto es la duración total del proyecto y la clasificación de tareas según prioridad.

Este modelo de proyecto fue el primero de su tipo, y supuso un nuevo impulso para la administración científica, fundada por el fordismo y el taylorismo. No son muy comunes otros tipos de modelos de proyectos, prácticamente todos se basan en PERT de algún modo. Solo el método de la ruta crítica (CPM) de la Corporación DuPont fue inventado casi en la misma época que PERT.

La parte más famosa de PERT son las Redes PERT, diagramas de líneas de tiempo que se interconectan.

Malla PERT

Una malla PERT permite planificar y controlar el desarrollo de un proyecto. A diferencia de las redes CPM, las redes PERT trabajan con tiempos probabilísticos.

Normalmente, para desarrollar un proyecto específico lo primero que se hace es determinar, en una reunión multidisciplinaria, cuáles son las actividades que se deberán ejecutar para llevar a término el proyecto según los requerimientos establecidos, cuál es la precedencia entre ellas y cuál será la duración esperada de cada una.

Principios

Estos tres principios deben respetarse siempre a la hora de dibujar una malla PERT:

  • Principio de designación sucesiva: se nombra a los vértices según los números naturales, de manera que no se les asigna número hasta que han sido nombrados todos aquellos de los que parten aristas que van a parar a ellos.
  • Principio de unicidad del estado inicial y el final: se prohíbe la existencia de más de un vértice inicial o final. Solo existe una situación de inicio y otra de terminación del proyecto.
  • Principio de designación unívoca: no pueden existir dos aristas que tengan los mismos nodos de origen y de destino. Normalmente, se nombran las actividades mediante el par de vértices que unen. Si no se respetara este principio, puede que dos aristas recibieran la misma denominación.

Duración de una actividad

Para estimar la duración esperada de cada actividad es también deseable tener experiencia previa en la realización de tareas similares. En planificación y programación de proyectos se estima que la duración esperada de una actividad es una variable aleatoria de distribución de probabilidad Beta Unimodal de parámetros (a, m, b) donde:

Duración de una actividad

En un dibujo de una malla PERT podemos distinguir nodos (representan instantes en el tiempo, específicamente el instante de inicio de una o varias actividades y simultáneamente el instante de término de otras varias actividades) y arcos (representan las actividades, que tienen un nodo inicial y otro de término donde llega en punta de flecha). Asociada a cada arco está la duración esperada de la actividad. Se puede dotar de más información un diagrama de actividades representando estas con una valoración de complejidad para minimizar el efecto de cuello de botella.

Dibujo de una malla PERT

Existen dos metodologías aceptadas para dibujar una malla PERT:

  • "Actividad en el Arco"
  • "Actividad en el Nodo", más utilizada en la actualidad
Archivo:Pert2.jpg
Red PERT.

Cada nodo contiene la siguiente información sobre la actividad:

  • Nombre de la actividad;
  • Duración esperada de la actividad (t);
  • Tiempo de inicio más temprano (ES = Earliest Start);
  • Tiempo de término más temprano (EF = Earliest Finish);
    Archivo:Mallapert.png
    Otra forma de representar la red PERT
  • Tiempo de inicio más tardío (LS = Latest Start);
  • Tiempo de término más tardío (LF = Latest Finish);
  • Holgura de la Actividad (H);

Por convención los arcos se dibujan siempre con orientación hacia la derecha, hacia el nodo de terminación del proyecto, nunca retrocediendo.

El dibujo de una malla PERT se comienza en el nodo de inicio del proyecto. A partir de él se dibujan las actividades que no tienen actividades precedentes, o sea, aquellas que no tienen que esperar que otras actividades terminen para poder ellas iniciarse. A continuación, se dibujan las restantes actividades cuidando de respetar la precedencia entre ellas. Al terminar el dibujo de la malla preliminar, existirán varios nodos ciegos, nodos terminales a los que llegan aquellas actividades que no son predecesoras de ninguna otra, es decir aquellas que no influyen en la fecha de inicio de ninguna otra, estas son las actividades terminales y concurren por lo tanto al nodo de término del proyecto.

Cálculo de los tiempos de inicio y terminación más tempranos

El tiempo de inicio más temprano “ES” (Early Start) y de terminación más temprano “EF” (Early finish) para cada actividad del proyecto, se calculan desde el nodo de inicio hacia el nodo de terminación del proyecto según la siguiente relación: La duración esperada del proyecto (T) es igual al mayor de los tiempos EF de todas las actividades que desembocan en el nodo de finalización o terminación del proyecto.

Cálculo de los tiempos de inicio y terminación más tardíos

El tiempo de inicio más tardío "LS" (Latest Start) y de finalización más tardío "LF" (Latest finish) para cada actividad del proyecto, se calculan desde el nodo de término retrocediendo hacia el nodo de inicio del proyecto según la siguiente relación: 

LS = LF - t
Donde (t) es el tiempo esperado de duración de la actividad y donde LF queda definida según la siguiente regla:
  • Regla del tiempo de terminación más tardío:
El tiempo de terminación más tardío, LF, de una actividad específica, es igual al menor de los tiempos LS de todas las actividades que comienzan exactamente después de ella.
El tiempo de terminación más tardío de las actividades que finalizan en el nodo de terminación del proyecto es igual a la duración esperada del proyecto (T).

Holguras, actividades críticas y rutas críticas

La holgura de una actividad es el tiempo que está disponible para, ya sea atrasarse en su fecha de inicio, o bien alargarse en su tiempo esperado de ejecución, sin que ello provoque retraso alguno en la fecha de término del proyecto. Se calcula de cualquiera de las siguientes formas:

H = LF – EF
H = LS – ES

Actividades críticas

Se denomina actividades críticas a aquellas actividades cuya holgura es nula y que por lo tanto, si se retrasan en su fecha de inicio o se alargan en su ejecución más allá de su duración esperada, provocarán un retraso exactamente igual en tiempo en la fecha de término del proyecto.

Rutas críticas

Se denomina rutas críticas a los caminos continuos entre el nodo de inicio y el nodo de terminación del proyecto cuyos arcos componentes son todos actividades críticas.

Las rutas críticas se nombran:

  • o por la secuencia de actividades críticas que la componen
  • o por la secuencia de nodos por los que atraviesa.
Un proyecto puede tener más de una ruta crítica pero al menos tendrá siempre una.

Holgura total

La holgura total es el intervalo durante el cual una operación, que se inicia a partir de las fechas más tempranas, se puede desplazar hacia el futuro sin que se vean afectadas las fechas más tardías de las operaciones sucesoras o la fecha final extrema del grafo.

La holgura total puede ser menor que, mayor que o igual a cero (holgura total = fin más tardío - fin más temprano).

Si las fechas más tempranas y más tardías de una operación coinciden en el mismo día, la holgura total será cero.

Las operaciones con la holgura total menor se denominan críticas.

El camino crítico es el camino a través del grafo en el que se ordenan las operaciones y sus relaciones de ordenación de manera que la holgura total es mínima. Por lo general, el camino crítico es el tiempo más largo que se necesita para elaborar el grafo.

Holgura libre

La holgura libre es el intervalo durante el cual una operación, que se inicia a partir de las fechas más tempranas, se puede desplazar hacia el futuro sin que se vean afectadas las fechas más tempranas de las operaciones sucesivas o la fecha de fin extrema del grafo. La holgura libre no puede ser inferior a cero ni mayor que la holgura total.

Matriz de asignación de responsabilidades - RACI

La matriz de la asignación de responsabilidades (RACI por las iniciales de los tipos de responsabilidad) se utiliza generalmente en la gestión de proyectos para relacionar actividades con recursos (individuos o equipos de trabajo). De esta manera se logra asegurar que cada uno de los componentes del alcance esté asignado a una persona o a un equipo.

Roles RACI

A cada tarea, actividad o grupo de tareas se le asigna uno de los roles RACI que se definen en la siguiente tabla:

Rol Descripción
R Responsible Responsable Este rol corresponde a quien efectivamente realiza la tarea. Lo más habitual es que exista sólo un encargado (R) por cada tarea; si existe más de uno, entonces el trabajo debería ser subdividido a un nivel más bajo, usando para ello la matriz RASCI.
A Accountable Aprobador Este rol se responsabiliza de que la tarea se realice y es el que debe rendir cuentas sobre su ejecución. Sólo puede existir una persona que deba rendir cuentas (A) de que la tarea sea ejecutada por su Responsable (R).
C Consulted Consultado Este rol posee alguna información o capacidad necesaria para realizar la tarea.
I Informed Informado Este rol debe ser informado sobre el avance y los resultados de la ejecución de la tarea. A diferencia del consultado (C), la comunicación es unidireccional.

En esta matriz se asigna el rol que el recurso debe desempeñar para cada actividad dada. No es necesario que en cada actividad se asignen los cuatro roles, pero sí por lo menos el de responsable (A) y el de encargado (R). Un mismo recurso puede tener más de un rol para una tarea, por ejemplo puede ser el encargado (R) y responsable (A) del mismo, en cuyo caso se anotará R/A.

Estas matrices se pueden construir en alto nivel (grupos de tareas generales) o en un nivel detallado (tareas de nivel bajo).

Una matriz de alto nivel se puede graficar con el listado de todos los entregables del proyecto definidas en la EDT versus los recursos definidos en el OBS. No todos los recursos tendrán necesariamente una entrada para cada actividad. Una matriz de bajo nivel se puede utilizar para designar roles, responsabilidades y niveles de autoridad para actividades específicas.

A continuación un ejemplo de una matriz RACI:

Actividad / Recurso Alba Brais Xosé Antía
Investigación R I I A
Planificación C A R I
Desarrollo A R
Verificación de Errores I R A

Conclusión

La Ley de Parkinson, enunciada por el británico Cyril Northcote Parkinson en 1957, afirma que "el trabajo se expande hasta llenar el tiempo disponible para que se termine"; es decir: el tiempo asignado a un proyecto viene a ser exactamente el que efectivamente tarda en desarrollarse: si el tiempo es escaso el desarrollo será peor en detrimento de su calidad, alcance, coste y/o tiempo.

Se han visto diferentes alternativas para la gestiónn y el control de proyectos informáticos. Cada una de ellas tiene asociadas distintas técnicas para la estimación de recursos, y la planificación y seguimiento del proyecto. Y se han revisado algunas de esas técnicas, para tener un enfoque global de la cuestión.

Relación con el sistema educativo

En los ciclos superiores:

  • En DAW - DAM - Entornos de Desarrollo (PES)
  • En ASIR - Implantación de Aplicaciones Web (PES)
  • En DAM - Sistemas de Gestión Empresarial (PES)

Bibliografía

Webgrafía

Referencias

PMBOK

Scrum y Kanban

RACI

Seguimiento temporal

Obtenido de «https://wiki.cifprodolfoucha.es/index.php?title=Gestión_y_control_de_proyectos_informáticos._Estimación_de_recursos._Planificación_temporal_y_organizativa._Seguimiento.&oldid=14843»