Buscar este blog

16 de diciembre de 2012

Mis consejos iniciales con Microsoft Project

Microsoft Project es una herramienta con una larga historia. Véase esta entrada en Wikipedia. Desde la aparición de la primera versión de Project para Windows en 1990, hasta la última en 2010, se han liberado 8 versiones más.

Se trata de una herramienta que ha mejorado mucho continuamente y sólo los expertos dominan todas sus funcionalidades. Sin embargo, hay unas funcionalidades básicas que pueden hacernos ganar mucho tiempo y claridad.

El siguiente vídeo explica las 8 funcionalidades básicas que a mí más me han ayudado.





 
Recomendación Nº1: Pantalla de Project = Table + View
La primera recomendación tiene que ver con interpretar la interfaz. Cuando vemos una pantalla de Project, hemos de interpretar que se trata de la combinación de una tabla más una vista. Project ofrece unas vistas prediseñadas en el menú “View”, pero cuando elegimos una, también estamos eligiendo una tabla por defecto. Por ejemplo, al seleccionar la vista “Resource Sheet” en el menú “View”, estamos también seleccionando la tabla “Entry”, aunque quizá no seamos conscientes de ello. Si seleccionamos la vista “Gantt Chart”, también estamos seleccionando la tabla “Entry”, pero podríamos cambiar a la tabla “Cost” y ya no aparecerían fechas de comienzo, fin, etc., sino información sobre los costes de cada tarea. Yo recomiendo que interpreten todas las pantallas de Project como la suma de dos paneles: A la izquierda aparece la tabla (columnas de campos preconfigurados, que siempre se pueden añadir u ocultar) y a la derecha aparece otro panel con la vista (distintas formas de presentar la información de las filas de la tabla).

Recomendación Nº2: Imprimir Imágenes GIF
Utilizar el menú de “Imprimir” es adecuado en determinadas ocasiones, pero no lo es cuando queremos utilizar la información de Project en una presentación PowerPoint, por ejemplo. Es mucho más recomendable utilizar el botón “Copy Picture” que permite escoger sólo la información relevante. De la imagen resultante también puede recortarse lo que no haga falta (por ejemplo, a veces no son significativos ciertos campos como los identificadores, los indicadores, las notas, etc.). ¿Cuántas veces hemos pensado que tenemos que hacer un Gantt en PowerPoint para poder presentar el cronograma de nuestro proyecto a nuestros clientes, o nuestros jefes? Bien usada, Project puede ahorrarnos todo ese tiempo, y a la vez generar un resultado con una imagen “más profesional”, no sólo cuando hay que pintar “gantts” sino para cualquier otra informacion valiosa del proyecto como usos de tareas o recursos, histogramas, diagramas de red, etc.
¿Le preocupa que Project siempre indique la fecha de inicio y todavía no se sabe? Tome supuestos: “suponiendo que el proyecto comienza el día 15 de octubre…” ¿Qué daño puede hacerle suponer una fecha de comienzo para su proyecto? Es el cliente indeciso (no usted) quien debe molestarse cuando vuelve a visualizar una presentación que indicaba que el proyecto podría haber empezado hace 6 meses. Ahora tiene mucha prisa, el proyecto ya debería estar terminando. ¡Lástima, debería haberse decidido antes!

Recomendación Nº3: Comenzar por la tarea resumen (número 0)
¿Saben cómo distingo yo a una persona que usa Project sólo para pintar gantts? Si veo que su gantt comienza con la tarea número 1, ya sé que esta persona no usa Project como es debido. Si usted marca el checkbox “Tools > Options > View > Show project summary task”, verá que en su vista “Gantt” aparece una tarea resumen con el nombre del proyecto. Esta tarea es muy importante porque agrega toda la información consolidada de plazos, costes, horas, retrasos, etc. Sirve para consolidar la información agregada del proyecto en los informes de Project.

Recomendación Nº4: No usar indiscriminadamente las fechas de inicio y fin
Cuando en Project escribimos la fecha de inicio de una tarea, estamos introduciendo la restricción “Start No Earlier Than” (empezar no antes de esa fecha): cambiar la duración altera la fecha de fin. Cuando escribimos la fecha de fin, estamos introduciendo una restricción “Finish No Earlier Than” (finalizar no antes de esa fecha): cambiar la duración altera la fecha de inicio. Cuando planificamos el cronograma, generalmente comenzamos identificando tareas, después las secuenciamos y posteriormente indicamos duraciones. En estas etapas iniciales, yo no aconsejo escribir fechas de inicio y fin, yo prefiero que Project las calcule para tener una primera información sobre la duración total y el camino crítico, asumiendo que todas las actividades comienzan tan pronto como sea posible. A la hora de desarrollar el cronograma, cuando tomamos decisiones de solapar o secuenciar, asignar recursos y nivelar sus cargas, etc., para mí es entonces el mejor momento para indicar restricciones de inicio y fin. Ya tendremos más información sobre las tareas y conoceremos mejor sus restricciones.

Recomendación Nº5: No usar duraciones con decimales
Una duración de 1 día significa que todos los recursos asignados a esa tarea ese día tienen trabajo ese día, pero no es necesario indicar cuantas horas: el esfuerzo planificado para ese día puede variar. Planificar la duración para una tarea un determinado día significa que la tarea tiene horas de trabajo ese día, y que una tarea dependiente comenzará el día siguiente. El campo duración no es sinónimo de esfuerzo. Cuando se planifica la duración con decimales, por ejemplo 0,25 días, generalmente se quiere expresar que no se emplean 8 horas, sino 2 horas. Cuando esto se hace así, quizá sea síntoma de que se esté confundiendo duración con esfuerzo. Si queremos que una tarea se haga durante la mañana del día 15 y ya no se hace nada más en el proyecto ese día, pongamos duración 1 día y asignemos 4 las horas de trabajo previstas en la vista “Resource Usage”. Project permite que una tarea dure 0,5 días, por ejemplo. Si esta tarea se hace en el turno de mañana, y la tarea siguiente se hace en el turno de tarde, es correcto poner 0,5 días. Pero generalmente no planificamos así: Lo que queremos decir cuando ponemos 0,5 días para esa tarea, es que dura 4 horas. Cuando asignamos duraciones con decimales puede que estemos cometiendo un error de concepto.

Recomendación Nº6: Entrar información en los campos de datos, directamente
Project tiene asistentes (wizards) para asignar recursos y secuenciar actividades. Mi consejo es que esta información sea introducida directamente, como si fueran fórmulas con variables, separadas por “;”. Por ejemplo, para indicar que la tarea 4 debe terminar dos días antes que la 2 y debe comenzar tres días después que la 3, puede introducirse directamente así en el campo “Predecessors” = 2FF-2d; 3SS+3d. Otro ejemplo:  para indicar que una tarea consume mientras dura toda la disponibilidad del recurso JB, una cuarta parte de las horas disponibles del recurso LD y se prevé que habrá que reservar 5 noches de hotel para realizarla, puede introducirse directamente así en el campo “Resources” = JB;LD[50%];Hotel[5]. Introducir así los recursos tiene dos efectos: 1) Aparecen automáticamente en la hoja de recursos, si no estaban, sin necesidad de introducirlos en la hoja de recursos antes (esto es válido para los recursos “work”, no para los de tipo “material” como es el caso del Hotel); y 2) Project distribuye automáticamente estos recursos de manera uniforme desde la fecha de inicio a la fecha de fin de esa tarea.

Recomendación Nº7: Controlar información maestro-detalle
Puede utilizarse la opción de menú “Window > Split”, para visualizar relaciones maestro-detalle. En el siguiente ejemplo, en el panel de arriba (maestro) visualizamos la vista Gantt Chart, en el panel de abajo visualizamos la vista “Resource Usage”. Cuando arriba pulsamos la fila correspondiente a la tarea 9, abajo aparecen todos los recursos que se usan en dicha tarea. Esta forma de presentar la información puede ser muy útil para controlar el cronograma.



Recomendación Nº8: Utilizar proyectos “maestros” para visualizar varios proyectos a la vez
Puede utilizarse la opción de menú “Window > New Window”, para seleccionar y visualizar varios proyectos a la vez.


Este post es una transcripción de un artículo que escribí para el curso online de Project Management de IEDGE. Pueden ver otros artículos míos generados para IEDGE pulsando aquí.