Analisis de valor generado (CPI y SPI)

 

Que es el valor generado?

Es un metodo para medir el desempeño de un proyecto, compara la cantidad de trabajo que fue planeado como lo que realmente fue realizado para determinar si se desempeño segun lo previsto

Los administradores de proyectos usan varios tipos de cálculos e indicadores para medir el progreso de un proyecto. Cada proyecto es planeado con un cronograma de trabajo a realizar, y el costo de los trabajos previstos. A lo largo del proyecto, medir el desempeño de los índices de costos y cronograma le dice a los gerentes de proyecto si el proyecto marcha ajustado al calendario o si deben realizarse ajustes.

CPI

El Índice de Desempeño de Costos (CPI, por sus siglas en inglés) mide la eficiencia del uso de recursos o eficiencia de costos para un proyecto. Un CPI mayor a 1 indica que el valor del trabajo cumplido es mayor que la cantidad de recursos usados en el proyecto. UN CPI menor a 1 indica que el valor del trabajo completado es menor al de los recursos gastados.

Calcular el CPI

El CPI es igual al valor obtenido (EV, por sus siglas en inglés) del trabajo realizado dividido entre el costo real del trabajo realizado (ACWP, por sus siglas en inglés). El CPI para proyectos gubernamentales es calculado dividiendo el costo presupuestado del trabajo realizado (BCWP, por sus siglas en inglés) entre el costo real de trabajo realizado (ACWP).

 

SPI

El Índice de Desempeño del Cronograma (SPI, por sus siglas en inglés) mide la eficiencia del trabajo y el progreso de un proyecto, comparando el trabajo real realizado con el trabajo planeado del proyecto. Si el SPI es mayor o igual a 1, el proyecto está exactamente ajustado al cronograma. Un SPI mayor a 1 indica que el proyecto marcha antes de lo previsto, mientras que un SPI menor a 1 indica que el proyecto está retrasado.

Calcular SPI

El SPI es calculado dividiendo el trabajo actual realizado (P) por la cantidad de trabajo planeado (SW, por sus siglas en inglés). Para proyectos gubernamentales, el SPI se calcula dividiendo el costo presupuestado de trabajo realizado (BCWP, por sus siglas en inglés) por el costo presupuestado de trabajo agendado (BCWS, por sus siglas en inglés).

Stakeholder

¿Que es un stakeholder?

Un individuo, grupo u organización, quien podría afectar, ser afectado o percibirse como afectado por una decisión, una actividad o el resultado final de proyecto.

 

 

Para identificar un stakeholder, debes hacerte las siguientes preguntas
• ¿Quién va a hacer el trabajo?
• ¿Quién es el administrador del proyecto?
• ¿Quién paga por el proyecto?
• ¿Quién consumirá el producto o servicio?
• ¿Quiénes se verán afectados positiva o negativamente del proyecto?

Matriz de poder/interes

La matriz de stakeholders es una herramienta que se utiliza para recopilar, clasificar, analizar y jerarquizar de manera sistemática información cualitativa y cuantitativa referente a todas aquellas personas, instituciones u organizaciones involucradas o interesadas en el proyecto, lo que permite determinar los intereses particulares que deben tenerse en cuenta a lo largo del proyecto. La utilización de esta herramienta de análisis permite clasificar a los involucrados en el proyecto según sus niveles de interés y poder sobre él, lo que facilita la priorización de los stakeholders más importantes para desarrollar así las estrategias de gestión correspondientes.

Razones por la que se atrasan los proyectos durante la ejecucion

Muchas veces la razón por la que se retrasan los proyectos es porque no toman en cuenta los riesgos que pueden ocurrir durante su ejecución y no tienen un plan de contingencia para solucionarlo y esto provoca el retraso del proyecto. También cuando los recursos no son dados al momento que se necesitan esto puede causar otro retraso en el proyecto o simplemente cuando no estas supervisando que tu equipo este realizando las tareas que les corresponde a cada quien también esto afecta en el tiempo de realización del proyecto.

Otro retraso que puede suceder es que el cliente durante el proyecto te esté dando nuevos requisitos para el proyecto esto claramente provoca un retraso ya que tienes que adecuar con el tiempo que llevas una nueva tarea que te dio el cliente y algunas veces al final del proyecto le presentas como va a quedar el cliente se muestra insatisfecho y decide cambiar varias cosas y esto provoca un retraso más. Muchas veces los proyectos requieren papeleos y esto lleva a que se retrase ya sea porque el papel que se necesita no lo tendrán en el tiempo que uno pensaba y tenia establecido por el proyecto.

 

Problemas con multitasking

El multitasking, hacer varias tareas de manera simultanea, surge dentro de la administración de proyectos cuando nos encontramos con una gran carga de trabajo y queremos terminar varias cosas al mismo tiempo.

Dentro de esto nos encontramos con el concepto de thrashing, que es el cambio constante de una tarea o de un proyecto a otro a medida que van cambiando las prioridades. Puede llegar a un punto en el que por estar haciendo varias cosas a la vez, no se termina ninguna actividad.

Utilizamos el multitasking para manejar un flujo de trabajo desmedido,  pero puede llegar a atrasarnos más debido q eu por estar cambiando de tareas constantemente, no llegamos a una velocidad o mindset óptimo para realizar la tarea. De esta forma, el trabajo no se realiza de forma eficiente.

En los proyectos, se ha demostrado que comenzar múltiples proyectos que se están trabajando en paralelo es mucho menos eficiente que terminar uno antes de comenzar el siguiente.

En conclusión, a pesar de que el multitasking parece una buena opción para aumentar nuestra productividad, en realidad lo único que logramos al hacer varias tareas al mismo tiempo es bajar la calidad de nuestro trabajo y perdemos más tiempo sin darnos cuenta.

Pasos para estimar duración real del proyecto

1. Generar las duraciones máxima, mínima, probable y más probable de todas las tareas del proyecto
2. Obtener la distribución de cada tarea
3. Correr simulaciones (100, 1000, 1000000 de veces) para conocer la probabilidad de duración del proyecto
4. Deducir la duración del proyecto con un porcentaje de efectividad

Proyecto Ágil

La gestión ágil de proyectos es un enfoque iterativo para planificar y guiar los procesos del proyecto.

Al igual que en el desarrollo de software ágil, un proyecto ágil se completa en pequeñas secciones llamadas iteraciones. Cada iteración es revisada y criticada por el equipo del proyecto, que puede incluir representantes de la empresa cliente, así como empleados. Los conocimientos adquiridos a partir de la crítica de una iteración se utilizan para determinar cuál debe ser el siguiente paso en el proyecto. Cada iteración del proyecto está programada normalmente para ser completada dentro de dos semanas.

El principal beneficio de la gestión de proyectos ágiles es su capacidad para responder a los problemas que puedan surgir a lo largo del transcurso del proyecto. Hacer un cambio necesario para un proyecto en el momento adecuado puede ahorrar recursos y, en última instancia, ayudar a entregar un proyecto exitoso a tiempo y dentro del presupuesto.

Debido a que la gestión ágil se basa en la capacidad de tomar decisiones con rapidez, no es adecuada para las organizaciones que tienden a deliberar sobre cuestiones durante un período prolongado o para aquellos que llevan las decisiones a un comité.

Manifiesto Ágil y sus 12 Principios:

Manifiesto:

Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas Software funcionando sobre documentación extensiva Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.

#1 – Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

#2 – Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

#3 – Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.

#4 – Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

#5 – Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

#6 – El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus
miembros es la conversación cara a cara.

#7 – El software funcionando es la medida principal de progreso.

#8 – Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios
debemos ser capaces de mantener un ritmo constante de forma indefinida.

#9 – La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

#10 – La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

#11 – Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

#12 – A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Anti patrones en administración de proyectos

Los anti patrones son practicas comunes y erróneas en la administración de proyectos que pueden conducir al fracaso del mismo. Es importante conocerlos para poder identificar y evitar su practica. A continuación se mencionan algunos de ellos.

1.- Ley de Brooks: es un principio utilizado en el desarrollo de software que afirma que añadir más efectivos a un proyecto de software en retraso, lo retrasará más. Esto se basa en que cuando se incorpora una persona en un proyecto, éste se ralentiza en lugar de acelerarse ya que se tiene que acondicionar el nuevo elemento.

2.- Marcha de la muerte: es cuando los miembros del proyecto sienten que esta destinado a fallar, o requieren una cantidad excesiva de trabajo, el ambiente del proyecto es malo y refleja que sera un total fracaso ya que los miembros del equipo están forzados a trabajar por sus superiores en lugar de por su propia voluntad.

3.- Humo y espejos: este anti patrón se usa para describir cuando un proyecto se presenta como algo espectacular y no existe todavía. Esta estrategia se usa para atraer clientes y patrocinadores ya que se describen las funcionalidades del proyecto como se ya estuviera terminado, esto no se recomienda ya que a la hora de la verdad resulta imposible o extremadamente difícil de completar.

4.- Ley de Hofstadter: dice que da lo mismo lo mucho que planifiquemos una tarea y lo pesimistas que seamos en nuestras estimaciones, la tarea siempre va a completarse fuera de fecha. Es más, incluso si somos pesimistas sobre nuestra previsión pesimista y además le añadimos un colchón de tiempo para poder cumplir con los plazos cómodamente, según la Ley de Hofstader, nos equivocaremos con nuestra estimación.

5.- Sobreingenieria: En inglés existe el término over-engineering que se refiere a resolver un problema aplicando más ingeniería de la necesaria. Aunque me parece fea, la traducción al español creo que sería sobreingeniería. Considero que en los proyectos de informática esto es algo bastante frecuente. Hay ciertos atributos de software que son mal vistos en su falta, pero sin embargo no son castigados en su exceso.

6.- Corrupcion del Alcance: (“Scope Creep”) es la adición de funciones y funcionalidad sin considerar los efectos sobre el tiempo, los costos y los recursos, o sin la aprobación del cliente. También conocido como: Adiciones al Alcance; Alteración del Alcance; o Cambio Mayor del Alcance; o Deslizamiento de Alcance.

 

 

Planear la ambiguedad

Roadmap: es una planificación del desarrollo de un software con los objetivos a corto y largo plazo, y posiblemente incluyendo unos plazos aproximados de consecución de cada uno de estos objetivos. Se suele organizar en hitos o «milestones», que son fechas en las que supuestamente estará finalizado un paquete de nuevas funcionalidades.

La expresión Prueba y error, es un método heurístico para la obtención de conocimiento, tanto proposicional como procedural. Consiste en probar una alternativa y verificar si funciona. Si es así, se tiene una solución. En caso contrario (resultado erróneo) se intenta una alternativa diferente.

• Orientado a soluciones. No se intenta descubrir por qué funciona una solución. Solo se aspira a lograrla.
• Problema específico. No se trata de generalizar soluciones a otros problemas.
• No óptimo. Se enfoca a encontrar solo una solución: no todas, ni la mejor.
• Costoso. Se requieren diversos medios para realizarse, pero no siempre es seguro un resultado positivo.

ASAP y ALAP

Identificar cuándo se realizarán las actividades:

• Tan pronto como sea posible
• Tan tarde como sea posible

 

Ruta crítica

¿Qué consideramos como ruta crítica en un proyecto?

Es la ruta más larga en el proyecto en términos de duración y podemos encontrarla en el diagrama de red. Definido formalmente es: La secuencia de actividades en la planeación de un proyecto que deben ser completadas a tiempo para que el proyecto sea completado en el tiempo establecido.

La duración del proyecto, definido por la ruta crítica, se le conoce también como makespan. Cualquier atraso en las actividades de la ruta crítica causarán un atraso en el proyecto.

Esto actua como la base para la preparación de la planeación además de una herramienta para la administración de un proyecto. Además de identificar las tareas que deben de ser completadas con mayor urgencia para terminar el proyecto a tiempo, también permite estimar el tiempo mínimo necesario para completar el proyecto.

Pasos para encontrar la ruta crítica

1. Hacer una matriz de dependencia de todas las actividades del proyecto
2. Elaborar el diagrama de red.
3. Añadir los tiempos al diagrama.

 

Ruta crítica en un diagrama de red.

Ruta crítica en un diagrama de Gantt