IEDGE – Recomendaciones Iniciales sobre 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. A continuación se explican algunas de las que a mí más me han ayudado.
Recomendación Nº1: Pantalla de Project = Table + View
La primera recomendación, más que una funcionalidad, es una recomendación a la hora de 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 «Task Usage», también estamos seleccionando la tabla «Usage», 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.
Mi primera recomendación es 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 cada fila). Es muy útil que preconfiguremos la barra de herramientas con los combobox “Table” y “View” para poder saber en cada momento qué información estamos viendo y para poder cambiarla con un click.
Nota: En este programa usaremos la notación View(Table) para indicar la pantalla de Project que estamos viendo en cada momento: Para la imagen del ejemplo usaremos la notación Gantt (Entry).
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.
¿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ían haber iniciado el proyecto antes!
Recomendación Nº3: Los Gantt deben 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.
En mi opinión, utilizar la tarea número “1” como resumen es un error, sobre todo cuando necesita ver varios proyectos a la vez.
¿Quizá este checkbox debería estar marcado por defecto?
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.
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.
Resumiendo: No impongan fechas de inicio y fin antes de secuenciar, nivelar, o indicar duraciones.
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 cuántas, el número de horas 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 se usa para determinar 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. Si es así, esto es sintoma 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 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. Aquí está el 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-2 d; 3SS+3 d
Por 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 antes en la hoja de recursos (esto es válido para los recursos “work”, no para los de tipo “material” como es el caso del hotel); y 2) se distribuyen estos recursos uniformemente desde la fecha de inicio a la fecha de fin de esa tarea.
También es importante saber que se puede inicializar el esfuerzo que almacena Project para esa tarea, simplemente suprimiendo el valor de ese campo. Project tiende a mantener el esfuerzo constante, por eso cuando en la tarea del ejemplo anterior cambiamos la duración al doble de días, las asignaciones de esfuerzo se reducen a la mitad. Es decir, si cambiamos “Duration” = 10d, automáticamente “Resources” = JB[50%];LD[25%];hotel[2,5]. Esto puede ser una molestia si todavía no tenemos claro el esfuerzo. Si queremos inicializarlo, simplemente pulsemos el botón suprimir encima del campo “Resources” antes de cambiar la duración.
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.
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.
En el siguiente ejemplo, se ven cómo aparece un Gantt consolidando la información de los 2 proyectos X e Y.
¡Quedo a la espera de sus comentarios!
Profesor del área de Dirección de las Operaciones
* Los contenidos publicados en este post son responsabilidad exclusiva del Autor.
¡Pronto grandes sorpresas en Facebook, Twitter y Youtube!:
- Síganos en Twitter
- Hágase fan en Facebook (IEDGE – The European Business School es la Escuela de Negocios en español con mayor número de fans.. ¡Averigüe por qué!)
- Acceda a nuestros videos en Youtube
Amigo
comento el día 11 de febrero a las 11:12 am (#)
Muchas gracias por publicar todos estos artículos. A parte de que están muy bien explicados, el orden y distribución de los mismos es excelente.
!!! GRACIAS !!!