10 REGLAS DE ORO AL TRABAJAR CON MS PROJECT.


Buenas,

Este post está extraído de una presentación que hubo en la conferencia de Project que tuvo lugar en Febrero (Project 2014 Conference.) Steffen Reister, de TPG, compartió sus reglas de oro y experiencias en la sesión que puede encontrarse en el siguiente enlace:

https://channel9.msdn.com/Events/Project/2014/PC234

Nos ha parecido interesante ofreceros un breve resumen de lo que se comentó en dicha sesión.

REGLA 1: Definir la fecha de comienzo del proyecto en “Projecto \ Información de Proyecto”

Project por defecto siempre hace sus cálculos teniendo en cuenta la fecha de comienzo (o finalización)

Debemos tener cuidado si usamos la primera tarea del plan de proyecto para definir la fecha de comienzo del proyecto. Si usamos un proyecto en blanco, utiliza por defecto la fecha actual.

REGLA 2: Definir el tipo de tarea en “Archivo \ Opciones”

Trabajo=Duración*Unidades*Horas/Día

      variable variable fijo (configuración del calendario)

Unidades fijas

Duración fija

Trabajo fijo

Resulta importante entender los tipos de tareas

REGLA 3: Sigue el principio de “caja negra”

Crea paquetes de trabajo, por ejemplo, agrupaciones de 6-10 tareas

Coloca cada paquete de trabajo  o tareas debajo de una tarea resumen y conecta dichos paquetes

Esto ayuda a controlar (administrar) qué entra y sale

Coloca hitos al final de las “cajas negras” y conéctalas en orden.

Indica el final de cada fase, asociándola con un hito. De esta manera, al colapsar las fases, siempre podremos ver la estructura del proyecto, incluyendo las dependencias (esto no ocurre así, si conectamos tarea a tarea.)

Nunca conectes tareas resumen. Es recomendable conectar al mismo nivel. Nivel 1 con nivel 1, nivel 2 con nivel 2, etc

Definamos las “cajas negras”

La estructura empieza a nivel de fase

Cada tarea pertenece a una resumen

 

REGLA 4: Permite a Project hacer sus cálculos – ¡ No edites las fechas !

La fecha de inicio y de fin son editables. También son calculadas por Project

Si editas las fechas de inicio y fin, puedes causar problemas (por ejemplo, puede añadir restricciones (constraints)

Este tipo de restricciones puede causar que aparezcan mensajes del tipo “Has movido la tarea Z … Esto es antes de …, etc” Elije OK para continuar, o Cancela, etc

Si ves esto, es recomendable leer con atención, y elegir con criterio.

Si añade un icono de un calendario, no tenemos más que borrar dicho icono. Esto eliminará la restricción, y pondrá la fecha original

 

REGLA 5: Usa Hitos para determinados Eventos y Fechas

REGLA 6: Usa “Fechas Límite” en vez de restricciones

REGLA 7: Evita finales abiertos en tareas resumen

El primer y último elemento en un plan de proyecto debiera ser un hito

Cada elemento en un plan de proyecto debiera tener un sucesor, salvo el hito final

Todo debiera ir contra el hito final, el cual es la fecha final del proyecto

 

REGLA 8: Principio “Highlander”. Una tarea, un recurso

Es recomendable, cuando sea posible, tener un recurso para cada tarea. De esta manera es más sencillo controlar la programación. Independientemente, si existe la necesidad de añadir más recursos, no hay mayor problema en hacerlo.

El tipo de tarea tiene influencia en esto.

 

REGLA 9:  No deben existir asignaciones a recursos de tipo trabajo a nivel de tareas resumen

Esto puede confundir los cálculos

Trabajo = Duración * Unidades * Horas / Día

Con 2 recursos asignados a 3 tareas

Ejemplo:

Duración tarea 3 días * 100% * 8 horas = 24 horas

Duración tarea 2 días * 100% * 8 horas = 16 horas

Duración tarea 6 días * 100% * 8 horas = 48 horas

                                              = 88 horas

Si se asigna a la tarea resumen

Duración tarea 9 días * 200% * 8 horas =  144 horas

Esto puede tener un impacto tanto en el costo como en el tiempo

 

REGLA 10: Actualiza Project en la Fecha de Estado

No es raro encontrarnos con que las cosas no se han hecho a tiempo…

Es posible que haya que re-programar algunos elementos

Re-programar el plan de proyecto completo para que tenga en cuenta trabajo incompleto

Trabajo incompleto tiene que ser en el futuro

Digamos que tiene que ser finalizado el viernes. Antes de hacer nada, tomemos una línea base, y actualicemos el proyecto.

Re-programemos el trabajo incompleto para que empiece después (ver la Fecha de Estado) y decidamos luego si para el proyecto completo o determinadas tareas.

Esto moverá el trabajo incompleto después del final de la fecha anterior.

Actualicemos el proyecto para saber qué pasa con las fechas.

 

Esperamos os resulte de interés, un saludo

 

Jorge Puig

Comments (0)

Skip to main content