información  para la dirección de un proyecto bajo PERT

Generada por el modelo PERT para  una fecha (T)

-probabilidad de completar el proyecto en fecha (F)  establecida 

 -sucesos alcanzados y actividades terminadas

-actividades que deberían haber empezado

-actividades que deberian haber terminado

-actividades que deberían empezar y terminar en el próximo periodo

-actividades anticipadas con relación al tiempo de comienzo o de terminación previstos

-duración total estimada para una actividad

-duración restante o tiempo de la fracción de actividad que queda por realizar a la fecha del informe

-cantidad o porcentaje de proyecto realizada hasta la fecha o en el periodo de informe,  si se establecieron estos parámetros en el programa

-fecha en que debería terminar la actividad si se altero la fecha de comienzo

-tiempo que puede desplazarse el comienzo o la terminación de la tarea si se produjo cambio en el margen total.

-actividades añadidas o suprimidas desde el informe anterior

-cambios en las previsiones de tiempos de los anteriores informes

-márgenes negativos en relación con la fecha impuesta para la terminación del proyecto

proyectos imposibles quick kill

En una vieja drdobbs journal encontré el concepto quic-kill project o proyecto de calendario imposible
Un proyecto imposible es una aberración conceptual.
porque solo se hacen proyectos factibles o posibles los otros no .
independientemente de lo que ese buen articulo quiso decir (todavía lo encuentran si se busca quick kill project) Se trata de un proyecto:
1-recargado
2-mal planificado
Siempre la excusa es la urgencia , y la urgencia es eso: una excusa . El articulo de la revista plantea una organizacion alrededor de tres "documentos"
1-vision and socpe document que no es mas que la formulación de los objetivos del proyecto
2-estructuración de las actividades en red jerárquica
3-revisiones de código
Un proyecto recargado es (traducido a algún concepto conocido ) un proyecto donde todos los caminos se han vuelto críticos. es decir no hay ningún camino con holguras , si se atrasa cualquier actividad todo el proyecto se atrasara por lo menos en esa cantidad de atraso (mínimo)
Entendamos: los recursos están saturados todo el tiempo , es decir el contenido de las actividades es solo el básico (core) cualquier aspecto de coordinación o plantificación u entumezcan es inaplicable porque no hay tiempo!. Y los jefes consideran que deberían estar terminados ayer !
En el ámbito del software dicen que son proyectos sin gerenciacion , es decir llevado adelante por programadores (es que no queda otra no hay tiempo para trabajos de managment)
Estos proyectos son una verdadera calamidad , no puede salir nada bueno al final de ellos.
Los escritores confían en que con la ayuda espiritual de los objetivos, con la concentración en actividades esenciales y con la disciplina de las revisiones estructuradas , quizás puedan completarse exitosamente.
Exitosamente porque conseguirán los resultados (nada mas), es decir se hará código que ejecuta lo requerido , pero segurisimo no es el mejor programa posible . Porque todo es incertidumbre.
Dice: que en estos proyectos un miembro no sabe ni por donde empezar.
Mi interpretación es simple: aunque nada tiene sentido , porque los objetivos no son claros , las actividades no las podemos completar y tampoco podemos dar una mínima garantía de calidad de lo que estamos haciendo . En ese desorden hay un sentido: seguramente los objetivos están confusos entonces busquemos los resultados y/o metas para adivinar los objetivos . Solo encaremos actividades posibles o sea que tienen un principio , un fin , un esfuerzo posible y un producto tangible (en nuestro mundo intangible). Y ya que los plazos no dan para control de calidad , hagamos lo mínimo : revisiones de código.
Todo esta mal porque los elementos esenciales de un proyectos son los resultados esperados , una red de actividades factibles que aseguran el producto o resultado y un método que sea verificable. En medio de todo esto hablan de las estimaciones
Recodemos que las actividades humanas están enmarcadas en un contexto social y de necesidades personales. Oralmente el que no conoce tiende a tomar como buena una estimación del trabajo de robot o maquina . Ese es el contenido esencial o básico o mecánico de la actividad (si hiciéramos solo eso durante las 24 hs habría que tener en cuenta por ejemplo que vamos al baño , que necesitamos hidratarnos , que hay que desentumeserse y así .....) Y como sabremos entonces cuales son las restantes ? aparte de estudiar , hay que basarse en observaciones por lo menos de actividades parecidas y ejecutadas por un tiempo considerable . Caso contrario históricamente la subestimacion es de un 50% , en el caso de gente con experiencia alrededor del 30%
Tenga en cuenta también que el paso de una actividad a otra requiere (para software ) entre 11 a 30 minutos (tiempo de preparación)