Hace varios días retomé una reflexión que realizo periodicamente: ¿cuál es el alcance de una Oficina Técnica de Proyectos?
Las respuestas a esta pregunta pueden ser tan variadas como implementaciones de Oficina Técnica de Proyectos haya, pero con total seguridad debe existir un denominador común entre todas ellas.
Como resultado de esa reflexión, recientemente publiqué en slideshare una breve presentación en la que recogía una propuesta básica de ideas con las que trataba de responder a la pregunta que abre este post. No obstante, debido a que actualmente formo parte de la OTP de una organización, las ideas planteadas tienen un claro sesgo relacionado con mi desarrollo profesional. Es decir, el alcance que he esbozado en la presentación tiene los condicionantes que percibo en mi actual entorno, en el que la OTP es un equipo que actúa como capa intermedia entre los niveles tecnológico y de negocio de la organización. Además, estas ideas también están limitadas al no pretender realizar una relación exhaustiva de características de funcionamiento.
Cuando me pregunto qué debe hacer una OTP me surgen múltiples respuestas, todas ellas con tres conceptos comunes: coordinación, conocimiento, asesoramiento. De estas tres ideas generales se desprende la relación de acciones identificadas: anticipar los problemas y proponer soluciones; orientar la evolución de los sistemas de información proponiendo las líneas tecnológicas a seguir; gestionar los proyectos y controlar su ejecución, tanto en lo referido al seguimiento de plazos como a garantizar la calidad de las soluciones implementadas; identificar las necesidades de la organización; participar en el diseño de las soluciones para que se ajusten a las necesidades identificadas; canalizar las peticiones provenientes de la capa de negocio concretando los requerimientos de partida para facilitar la obtención de un análisis inicial; ofrecer información de soporte al nivel directivo para la toma de decisiones estratégicas.
A pesar de que desarrolle todas estas actividades, una OTP no podrá ofrecer todo su valor potencial si la organización no tiene a este equipo como referencia en el desarrollo del negocio y, consecuentemente, de los sistemas de información.
Por otra parte, desde mi punto de vista hay un tipo de tareas que no debe hacer una OTP, y que podría resumir como ejecutar los proyectos encomendados por la organización a terceros. Dentro de esta categoría incluyo, principalmente, cuestiones como la realización de tareas de mantenimiento y evolución de los sistemas de información, implementación de las soluciones evolutivas o correctivas de las aplicaciones de soporte al negocio, etc. La realización de tareas de este tipo supondría una pérdida de eficiencia al duplicar esfuerzos que deben ser asumidos por la empresa que ejecuta los proyectos en cuestión. En este sentido, la OTP no estaría aportando el valor añadido esperado por la organización.
Como resumen me ha parecido interesante representar sobre el diagrama del Ciclo de Deming (Plan-Do-Check-Act) las responsabilidades de una Oficina Técnica de Proyectos, ya que encajan prefectamente con los pasos Plan y Check.
En este punto se podría ampliar la discusión con la siguiente pregunta: ¿quién es el responsable de planificar las tareas a realizar en el proyecto? Si atendemos a la propuesta de roles de Scrum, la planificación de cada iteración es responsabilidad del Product Owner (persona que toma las decisiones del cliente) pero, ¿puede ser la OTP el Product Owner? En el caso de mi organización la respuesta es no.
Para concluir me gustaría retomar el comentario sobre el denominador común que hacía al principio. En este caso propongo tomar como referencia la guía PMBOK, que aborda la PMO (Project Management Office) desde una perspectiva abierta indicando que tiene «responsabilidades asignadas con relación a la dirección centralizada y coordinada de proyectos», señalando posteriormente funciones como el apoyo administrativo al establecimiento de políticas, metodologías y plantillas; la capacitación y asesoría a los directores de proyectos; la identificación de recursos necesarios en el proyecto; y la centralización de la comunicación entre directores de proyecto, patrocinadores, nivel directivo y otros interesados.
Seguramente con vuestra experiencia y aportaciones se podrá ampliar y mejorar esta primera aproximación. ¿Se animan a participar?
Saludos.
Rafa Feliciano 