Bienvenido

 

Estimadas y estimados participantes:

En este relanzamiento del Blog de la UCI, es un gusto recibirles y ofrecerles un espacio virtual en el que podamos establecer contacto y compartir conocimiento, intercambio de ideas y noticias.

En sus aportes, les pedimos respetar los derechos de autor, nombrando siempre sus datos bibliográficos, así como hacer uso de la libertad de opinión manteniendo la cordialidad.

La UCI quiere por este espacio mantenerle informado de nuevos eventos, noticias o actividades, e invitarlos a colaborar con nuestra comunidad virtual.

 

viernes, 11 de febrero de 2011

Problemas por mal uso de MS Project

Todo usuario de MS Project que no cuente con la capacitación indispensable para utilizar esta herramienta, definitivamente se va a encontrar con una cantidad de problemas sumamente relevantes, por lo que Carl Charfield, PMP y Co-autor de la serie paso a paso de Microsoft Project publicó en MPA (Microsoft Project Association) una exposición sobre esta temática, para evitar el fracaso en la gestión de los proyectos.

1. Intentar utilizar MS Project como una herramienta libre de brainstorming. Antes de empezar a trabajar con MS Project, recomienda tener claro qué tareas deben de ser llevadas a cabo y quién es el responsable de las mismas. En concreto nos remite a las plantillas que Excel incorpora por defecto para la gestión de proyectos, y una vez cubiertas proceder a su importación desde MS Project.
2. Especificar fechas fijas en vez de enlazar tareas. Si no efectuamos dicho enlace de la forma adecuada, reflejando las dependencias, la repercusión de un cambio de duración en una de ellas no se reflejará automáticamente en la planificación global.
3. Sobreestimar la capacidad de los recursos. Dado que por defecto MS Project asigna una capacidad de 100% a los recursos, pueden evitarse problemas a futuro no olvidándose del uso de calendarios y de una especificación lo más correcta posible de la capacidad máxima de dedicación de los recursos.
4. Confundir duración con trabajo. Como continuación al punto anterior, y especialmente en el caso de proyectos informáticos, los trabajadores del saber o del conocimiento (como los denomina el autor), rara vez trabajan en un proyecto a tiempo completo, son multitarea, distribuyendo su tiempo entre varias actividades y proyectos, por lo que no debe perderse de vista la diferencia entre duración de las tareas y trabajo necesario para ejecutarlas.
5. Pensar que la planificación condicionada por el esfuerzo tiene sentido. La planificación condicionada por el esfuerzo significa que si añado recursos a una tarea, el trabajo total permanece constante y se distribuye entre los recursos de acuerdo a la dedicación de los mismos. Por tanto, la duración de la tarea disminuye. Sin embargo, esta opción tiene un límite ya en muchos casos las tareas necesitan un período mínimo para ejecutarse con calidad.
6. Esperar que la redistribución automática de recursos altere la realidad. Hace referencia a que muchos usuarios esperan que la reasignación automática de recursos sea una fórmula mágica que en cualquier circunstancia concilie el exceso de trabajo con la capacidad limitada de los recursos, pero sin incrementar la duración total del proyecto.
7. Realizar el seguimiento del trabajo según el porcentaje completo. Cuando no se puede definir con exactitud lo que quiere decir un determinado porcentaje, muchas veces puede resultar confuso o crear sensaciones ilusorias basarse exclusivamente en el grado de avance expresado en porcentaje.
8. Detallar demasiado la planificación. En este punto se hace hincapié en que son necesarias las habilidades de un buen Jefe de Proyecto para llegar a establecer el nivel adecuado de detalle de la planificación, proponiendo varios consejos.
9. Creer que una buena herramienta de software de gestión de proyectos le convierte a uno en un buen jefe de proyecto.
10. Olvidar que la planificación no es el proyecto. Nos recuerda que son las personas y no el software quién ejecuta los proyectos.

No hay comentarios:

Publicar un comentario