EPM: ¿centralizada o descentralizada?
Este artículo forma parte de nuestra colección "From the Trenches". Describe cómo las organizaciones necesitan comprender los problemas que intentan resolver al decidir la implementación de un sistema de administración de proyectos. A menudo, implementar un sistema de administración de proyectos centralizado puede no ser la mejor respuesta.
Para descargar la versión de Word de este artículo, consulte EPM-Centralized or Decentralized?.
Para ver más artículos, consulte las notas del producto "Desde las trincheras".
EPM - ¿Centralizado o descentralizado?
He sido un defensor de Enterprise Project Management desde que ingresé por primera vez en la industria de administración de proyectos a principios de la década de 1980. Pensarías, entonces, que yo votaría siempre del lado de la administración centralizada de proyectos, pero eso no siempre es así. Vamos a analizar por un momento lo que queremos decir con Enterprise Project Management.
EPM puede significar muchas cosas diferentes para diferentes personas. Ya he descrito en otros artículos de esta columna cómo el foco de una implementación de EPM podría ser la administración de documentos para una organización y programaciones integradas para la siguiente. Sin embargo, Enterprise Project Management tiene en su núcleo la noción de que las personas deben interactuar entre sí en el ejercicio de administración de proyectos. Esto significa que el administrador de proyectos o el equipo de administración de proyectos no funcionan de forma completamente independiente. Pero, ¿significa eso que la única manera de lograr esta "interacción" es tener un sistema centralizado de programación de proyectos? No necesariamente. Para algunas organizaciones, el desafío de administración de proyectos podría ser la imposibilidad de generar informes de administración de proyectos de resumen para toda la empresa debido a que todos los proyectos se administran de forma ad hoc. En este caso, EPM podría lograrse simplemente con estándares de proyecto que se compartan entre todo el personal de administración de proyectos. Esto podría lograrse mejor con un grupo central de plantillas, materiales de entrenamiento, documentos y estándares de informes que todos puedan usar. Tal vez un sitio de SharePoint simple sería suficiente.
Para algunas organizaciones, el desafío de administración de proyectos podría ser programaciones personales ineficaces debido a la falta de comunicación entre los recursos sobre lo que están trabajando y cuál es su siguiente enfoque. En este caso, EPM podría lograrse mejorando la comunicación entre equipos y equipos. Las herramientas podrían ser tan sencillas como un calendario compartido, mensajería instantánea o un portal compartido donde las personas podrían enumerar cuáles son sus prioridades.
En algunas organizaciones, el desafío de administración de proyectos es conseguir progresos en los proyectos de desarrollo de programación. Si ese es el caso, es posible que las herramientas ya presentes en un producto como Visual Studio Team Services sean suficientes. Es bastante común en los proyectos de programación encontrar que muchas tareas se pueden completar en casi cualquier orden, por lo que es posible que los rigores de la programación de rutas críticas ni siquiera sean adecuados en función del tipo de desarrollo que se realice.
Recuerdo que hace unos años trabajé con el departamento de mantenimiento de una aerolínea. El personal tenía permiso para elegir sus propios horarios al principio de cada mes y si esto no estaba coordinado (como a menudo era el caso), era posible llegar a administrar un turno sólo para averiguar que nadie estaba trabajando. Su desafío de administración de proyectos no era "¿Cuándo se completará el trabajo?", era "¿alguien viene a trabajar?". En este caso, EPM se logró mediante la implementación de una herramienta de programación de turnos.
Incluso cuando centramos el desafío de EPM en las programaciones de proyectos, no es inmediatamente obvio que implementar un sistema centralizado de administración de proyectos es la única o la mejor respuesta. Merece la pena preguntar qué interacción debe tener el personal de administración del proyecto entre sí. Si deben colaborar periódicamente para resolver conflictos de recursos, para ver qué otras prioridades de la organización están apareciendo, o para ver cómo afectará el progreso de un proyecto a otro, entonces mirar una herramienta como Project Server tiene el sentido perfecto, pero a menudo terminan interactuando con organizaciones que ni siquiera han hecho esta pregunta de sí mismos.
En algunas organizaciones encontramos un pequeño número de programadores y un gran número de recursos. Incluso en una organización de buen tamaño, esta puede ser la estructura en función del sector y el tipo de proyectos que se realicen. No hace mucho tiempo me reuní con una organización que estaba segura de que habían elegido la solución adecuada para su desafío de EPM. Me pidieron que articulara la solución, pero, como de costumbre, les pedí que primero articulasen su problema de administración de proyectos.
Cuando terminaron de describir su entorno en una pizarra blanca, era evidente incluso para ellos que la solución que habían elegido no iba a resolver su problema.
En este caso, el problema era la falta de progreso del proyecto que estaba siendo notificado por un gran grupo de subcontratistas. El cliente determinó que lo que realmente tendría que hacer sería imponer un tipo de horas y un tipo de facturación de parte de horas a sus subcontratistas. Se desaconsejaba al Director del Programa. "Nunca podremos entrar en los contratos de subcontratistas", dijeron. Afortunadamente, un miembro del Departamento de Finanzas estaba presente. "Ya sabes", respondió esa persona, "una cláusula que les obliga a rellenar el parte de horas de nuestra elección ya está en el contrato del subcontratista". Problema resuelto.
La idea de recorrer el problema antes de llegar a la solución es una de la que hablo a menudo por aquí, pero es difícil de adoptar. El pensamiento lógico dictaría que el orden de determinar una solución automatizada sería:
Identificar el problema
Definición de la solución
Determinar si se debe (y, si es así, cómo) automatizar la solución
Las demostraciones automatizadas de soluciones en sitios web, vídeos y otros lugares nos hacen olvidar eso. No buscamos una solución, por supuesto, a menos que tengamos algún tipo de problema, pero las soluciones automatizadas parecen y suenan tan atractivas que terminamos haciendo esto:
Elección de la solución automatizada
Hacer que el problema se implemente la solución
Resuelva ese problema definiendo cómo se puede aplicar la herramienta automatizada a la solución.
Intente recordar cuál era el problema original.
El nuevo problema se convierte en la implementación de la solución durante bastante tiempo y luego semanas, meses o incluso un par de años por el camino alguien de la administración superior pregunta cuándo se resolverá el problema original y todos se miran bastante sorprendidos. Fue fácil olvidarlo.
A lo largo de los años he recomendado todo tipo de soluciones automatizadas posibles. Por supuesto, Project Server ha sido una de las opciones, pero también he recomendado una combinación de Microsoft Project Pro y SharePoint Server. He recomendado usar una combinación de Excel y Outlook. He recomendado usar partes de horas de terceros con Project.
Incluso una vez recomendé usar una gran pizarra blanca. Honesto. La organización era una con la que había hecho negocios durante años. La persona en cuestión tenía un rol inmobiliario y tenía que renovar contratos de arrendamiento a largo plazo en bienes raíces. Cuando me preguntó cuál era el problema, era claramente un problema de programación. La persona había perdido algunas fechas límite que eran importantes y estaba seguro de que una herramienta de administración de proyectos empresariales solucionaría el problema. La organización ya había pedido que los informes se distribuyesen a varios ejecutivos para que no se perdiesen las fechas límite futuras. "¿Cuántos usuarios habría?" Lo he preguntado. "Sólo yo", respondió. "¿Cuántos de estos proyectos hay a la vez?" Le pregunté "Siete u ocho", respondió. "Y cuántos de estos hitos de fecha límite se administran para cada proyecto "Es muy complicado. Hay media docena de fechas límite para cada una de ellas", me dijo.
Ya estaba claro para mí que no deberíamos estar instalando un gran sistema de EPM centralizado para este pobre tipo.
"¿Por qué no poner una gran pizarra blanca en el cubículo y usar algunos marcadores de colores para los diferentes hitos?" Lo he preguntado. "Podrías usar azul para el primero, verde para el segundo, rojo para el último, etc."
Tomó notas copiosas, fascinadas por el concepto. Dejé la empresa sabiendo que no había vendido ningún servicio o producto ese día, pero que había dejado a la persona decepcionada de que no pudiera implementar el sistema que había previsto. De camino a casa, mi teléfono sonó en el auto. Era él. "¿Podría explicar los diferentes colores para la pizarra blanca?", Preguntó.
Averiguar qué problemas intenta resolver antes de diseñar la solución y antes de elegir cómo automatizarla no solo ahorra dinero. Puede ahorrar una gran cantidad de tiempo dedicado a trabajar en elementos de la organización que no tenían un problema que necesitaba resolverse en primer lugar.
Cuando los problemas que intenta resolver se pueden resolver mejor con el software centralizado de administración de proyectos empresariales, entonces nada más realmente hará, pero el enfoque que habrá ganado articulando el problema le ayudará incluso allí. El equipo de implementación puede crear métricas de éxito que permitan que el proyecto se declare correcto cuando se hayan resuelto los problemas. ¿Centralizar o descentralizar? Enterprise Project Management se puede lograr con cualquiera de los dos.
Autor
Chris Vandersluis es el presidente y fundador de Montreal, HMS Software, un asociado certificado de Microsoft con sede en Canadá. Tiene una licenciatura en economía de la Universidad McGill y más de 30 años de experiencia en la automatización de sistemas de control de proyectos. Es un miembro de larga data del Project Management Institute (PMI) y ayudó a encontrar los capítulos de Montreal, Toronto y Quebec del Grupo de Usuarios de Microsoft Project (MPUG). Entre las publicaciones para las que Chris ha escrito se incluyen Fortune, Heavy Construction News, la revista Computing Canada y PMNetwork de PMI, y es columnista regular de Project Times. Enseña administración avanzada de proyectos en la Universidad McGill y a menudo habla en las funciones de asociación de administración de proyectos en Norteamérica y en todo el mundo. HMS Software es el editor del sistema de mantenimiento de tiempo orientado al proyecto TimeControl y ha sido asociado de soluciones de Microsoft Project desde 1995.
Chris Vandersluis puede ser contactado por correo electrónico en: chris.vandersluis@hms.ca
Si desea leer más artículos relacionados con EPM de Chris Vandersluis, consulte el sitio de orientación de EPM de HMS (https://www.epmguidance.com/?page_id=39).