De la job description a trabajar por objetivos
En los últimos años no dejamos de oir que muchos profesionales en las organizaciones están trabajando en 4 ó 5 proyectos a la vez. Esto no deja de ser sorprendente si a ello le añadimos la realización de las funciones que requiere su job description. El resultado: los proyectos se dilatan hasta la eternidad a través de reuniones infinitas.
En su día les contrataron para desempeñar una serie de funciones que ahora son prácticamente incapaces de llevar a cabo porque la organización ha invadido su agenda de proyectos y a menudo las reuniones son la excusa perfecta para dilatarlos y ganar tiempo. Sin embargo, trabajar por proyectos u objetivos se ha puesto de moda.
Si trabajar en base a una job description supone hacerlo en base a una serie de funciones o tareas, trabajar por proyectos es algo distinto -y no me refiero a hacer proyectos en una determinada función-. Esto es, dejar de lado en cierta manera las funciones o mejor liberar a los empleados de todas aquellas tareas que no aportan valor añadido y posiblemente traspasarlas a lo que sería equivalente a un centro de servicios compartidos, para trabajar en conseguir un objetivo concreto.
No es mejor una forma de trabajar que otra, sino como siempre, depende… depende una vez más de la cutura organizativa. En cualquier caso, lo que no es viable es trabajar con ambos modelos a la vez. Ello está llevando a que los empleados nunca vean tangibilizados los proyectos en los que están trabajando y, en consecuencia, a una inmensa desmotivación y desconfianza versus la compañía: «para qué… si al final no se va a hacer…»
Y ni que decir tiene los empleados de muchas áreas en las que no existía tradición alguna de trabajar por proyectos u objetivos, a quienes se ha puesto a trabajar de este modo y los que, por el contrario, solían trabajar así, lo hacen utilizando metodologías en cascada o secuenciales.
Las nuevas metodologías proponen la generación de pequeños entregables en un esquema de actividades que se pueden solapar o traslapar, ya sea en forma secuencial o con un enfoque totalmente solapado. Dentro de estas formas de trabajo, nos encontramos, por ejemplo, con el desarrollo ágil de SCRUM. Excelence Management lo explica muy bien en el siguiente esquema:
Por el contrario, el esquema de desarrollo en cascada se caracteriza por proponer actividades secuenciales, claramente agrupadas dentro de fases o ciclos del desarrollo del proyecto, propone hacer un análisis intensivo de requerimientos y se vuelve complicado volver a etapas previas del proyecto cuando se encuentran diferencias significativas en el alcance definido en etapas tempranas del mismo.
Y para acabar, el tiempo, esa magnitud física tan preciada… Demasiado a menudo vemos en las organizaciones personas que ejercen sus funciones y un sinfín de proyectos, todo a la vez, sin orden ni concierto y sin saber. Permítanme que recuerde a aquéllas lo que Einstein dijo:
La única razón para que el tiempo exista es para que no ocurra todo a la vez.
0 comentarios