A menudo, me encuentro con colegas que cuando les comento acerca de la gestión de proyectos, sueltan: “ Ah sí, yo también gestiono proyectos, habitualmente uso el MsProject ..”

Ni que decir que no salgo de mi asombro al constatar que a estas alturas del partido, la gestión de un proyecto se confunde con ir actualizando un GANTT, habitualmente en EXCEL !!

No creo conveniente volver a hacer hincapié en que gestionar un proyecto es mucho más que eso, y que si bien las herramientas de gestión son de una ayuda inestimable, no son más que eso, herramientas, que de ningún modo garantizaran el éxito en un proyecto.

Por lo general, si alguien se ha tomado “en serio  eso del project management”, será, con más o menos fortuna, un usuario avanzado de MsProject o similares. Habitualmente el proceso pasa por ir añadiendo tareas, ajustando in situ la vinculación y fechas de las mismas. Posteriormente, el seguimiento consistirá en ir ajustando lo previsto con la realidad.

Pretender llevar la gestión de esta manera, implica indefectiblemente, desconectar de la realidad que envuelve al proyecto. Hacer la planificación y seguimiento de un proyecto, es quizá lo menos importante. Un director de proyectos, no tiene como misión hacer un seguimiento y reporte más o menos exhaustivo. Su misión es conducir la realidad hacia los objetivos marcados, con especial cuidado del cliente. Difícilmente podrá tener éxito en su misión si no asume su rol principal, que es el de comunicar.

Dicha visión me hace pensar en la visión generalizada del papel que desempeña un director de proyectos, esto es,  del PM que anota y reporta la consecución de tareas tal que un notario.

El rol que se busca en las organizaciones, es aquel que constantemente está en contacto con el equipo, que conoce con antelación como se está desarrollando el proyecto, haciendo participes a todos los interesados. Es capaz  de detectar cuando un miembro terminara su tarea fuera de plazo, habla con él, detecta sus necesidades e inquietudes, se reúne con el cliente, le informa, recibe sus impresiones, las comunica al equipo… ¿Tiene alguna necesidad de ser un experto en aplicaciones?

Si tuvieseis que elegir entre los dos perfiles, ¿A quién escogeríais?

En un post anterior ya hicimos referencia a esta normativa, pero ahora podemos decir que ya esta aquí.

El pasado 31 de agosto entró en vigor la norma ”ISO21500: Guidance on project management”, que tratara de establecer las mejores prácticas en el ámbito de la gestión de proyectos.

Si bien ya hay alguna normativa específica para algunos de los procesos, tales como la ISO 31000 para gestión de riesgos, y la ISO 10006 para la gestión de la calidad en proyectos, hasta el momento no existía una normativa internacional sobre PROJECT MANAGEMENT, cosa que tal como ha avanzado la profesión en los últimos años, no dejaba de ser sorprendente.

En principio no podrá ser utilizada para certificación o servir de marco regulatorio, al contrario que otras, pero si ser una descripción de alto nivel acerca de cómo desarrollar la gestión de proyectos.

La norma se estructura en cuatro partes fundamentales:

1. Alcance
2. Términos y definiciones
3. Conceptos de Project Management
4. Procesos en Project Management

En cuanto a la previsión de futuro, hay que tener en cuenta que las normas ISO son tenidas como el referente de calidad de gestión, con lo que dicha norma pueda llegar a este nivel.

En muchos foros se apunta a que las empresas buscaran certificarse en ISO 21500 para diferenciarse de la competencia.

Un escenario plausible seria que las empresas que quieran ser referencia en Project Management, sigan las recomendaciones de la norma ISO 21500, y que soliciten los servicios de profesionales certificados en alguno de los estándares actuales, así que los que posean alguna certificación, seguirán diferenciándose en el mercado.

Es sin duda una buena noticia que el principal organismo de referencia regulador a nivel mundial haya decidido que la gestión de proyectos sea lo suficientemente importante para estar cubierta con una norma ISO.

Los requerimientos funcionales se describen mejor en forma de casos de uso, que se derivan de las características. Un caso de uso es una descripción de un sistema en términos de una secuencia de acciones. Debe ser un resultado observable o un valor para el actor (un actor es alguien o algo que interactúa con el sistema).

Los casos de uso:

- Son iniciados por un actor
- Modelan la interacción entre el interesado y el sistema
- Describen una secuencia de acciones
- Capturan los requerimientos funcionales
- Proporcionan algún valor para un actor
- Representan un completo y significativo flujo de eventos.

Especificación suplementaria

Las especificaciones suplementarias recogen aquellos requerimientos no funcionales (usabilidad, fiabilidad, rendimiento,..) y algunos requerimientos funcionales internos del sistema que, por tanto, son difíciles de contemplar en los casos de uso.

Creación de casos de prueba a partir de casos de uso

Tan pronto como se recopilan todos los requisitos, deberíamos diseñar una forma de comprobar si se implementan correctamente en el producto final. Los casos de prueba mostrarán a los evaluadores qué pasos deben realizarse para probar todos los requisitos. En este paso nos concentraremos en la creación de casos de prueba a partir de casos de uso. …