EPM: ¿centralizada o descentralizada?: notas del producto

Estas notas del producto forman parte de nuestra colección "Desde las trincheras". En ellas se describe cómo las organizaciones necesitan entender los problemas que intentan solucionar cuando deciden implementar un sistema de administración de proyectos. A veces, la implementación de un sistema de administración de proyectos centralizado puede no ser la mejor respuesta.

Para descargar la versión de Word de este documento, consulte ¿EPM centralizada o descentralizada?

Para ver más notas del producto, consulte las notas del producto "Desde las trincheras".

¿EPM centralizada o descentralizada?

He sido un defensor de la Administración de proyectos empresariales desde que me incorporé a la industria de administración de proyectos a principios de la década de 1980. Entonces se podría pensar que yo siempre estaría a favor de la administración centralizada de proyectos, pero no siempre es así. Analicemos por un momento lo que significa la Administración de proyectos empresariales.

EPM puede significar muchas cosas distintas para diferentes personas. Ya he comentado en otros artículos de esta columna cómo el enfoque de una implementación de EPM podría ser la administración de documentos para una organización y las programaciones integradas para la próxima. No obstante, la Administración de proyectos empresariales se basa en la idea de que las personas deben interactuar entre sí en la administración de proyectos. Eso significa que el gestor del proyecto y/o equipo directivo del proyecto no funcionan de una forma totalmente independiente. Pero ¿quiere eso decir que la única forma de conseguir esta "interacción" es tener un sistema centralizado de programación de proyectos? No necesariamente. En algunas organizaciones, el reto de la administración de proyectos podría ser la incapacidad de generar informes de administración de proyectos resumidos de toda la empresa debido a que los proyectos se administran en una base ad-hoc. En este caso, EPM podría conseguirse solo por tener estándares de proyecto compartidos entre todo el personal de administración de proyectos. Eso podría lograrse mejor con un grupo de plantillas, materiales de aprendizaje, documentos e informes estándar centralizados que todos los usuarios puedan usar. Quizás bastaría con un simple sitio de SharePoint.

En algunas organizaciones, el reto de la administración de proyectos podrían ser las ineficaces programaciones del personal debido a la falta de comunicación entre los recursos sobre lo que están trabajando y cuál es su próximo enfoque. En este caso, EPM podría lograrse mejorando la comunicación del equipo y la comunicación entre diferentes equipos. Las herramientas podrían ser tan simples como un calendario compartido, la mensajería instantánea o un portal compartido donde los usuarios podrían enumerar cuáles son sus prioridades.

En algunas organizaciones, el reto de la administración de proyectos es simplemente avanzar en la programación de proyectos de desarrollo. Si es el caso, las herramientas que ya están presentes en un producto como Visual Studio Team Services podrían ser suficientes. Es bastante común encontrar en proyectos de programación que muchas tareas pueden realizarse en casi cualquier orden, de modo que las exigencias de la programación de rutas críticas quizás no sean adecuadas según el tipo de desarrollo que se vaya a realizar.

Puedo recordar el trabajo de hace varios años en el departamento de mantenimiento de una línea aérea. El personal podía elegir sus propias programaciones al comienzo de cada mes y si no estaban coordinadas (como ocurría a menudo), era posible que solo al administrar un turno se descubriera que nadie estaba trabajando. El reto de la administración de proyectos no era "¿Cuándo se completará el trabajo?", sino más bien si "¿Va a venir alguien a trabajar?". En este caso, EPM se logró implementando una herramienta de programación de turnos.

Incluso cuando centramos el reto de EPM en las programaciones de proyectos, no es inmediatamente obvio que la implementación de un sistema de administración de proyectos centralizado sea la única o la mejor respuesta. Vale la pena preguntarse qué interacción debe tener entre sí el personal de administración de proyectos. Si deben colaborar con regularidad para resolver conflictos de recursos, para ver qué otras prioridades surgen en la organización o para ver cómo el progreso de un proyecto afectará a otro y luego ver como una herramienta como Project Server hace que todo tenga sentido. No obstante, suelo terminar la interacción con organizaciones que ni siquiera se han hecho esta pregunta.

En algunas organizaciones encontramos un número muy reducido de programadores y un número elevado de recursos. Incluso en una organización bien dimensionada, esta estructura puede depender del sector y del tipo de proyectos que esté llevando a cabo. No hace mucho tiempo me encontré con una organización que estaba seguro que tenía seleccionada la solución adecuada para sus retos de EPM. Me pidieron que propusiera la solución pero, como de costumbre, les pedí que antes me indicaran su problema de administración de proyectos.

En el momento en que describieron su entorno en una pizarra, 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 avances en el proyecto que un gran grupo de subcontratistas estaba notificando. El cliente determinó que lo que realmente tenía que hacer era imponer un tipo de parte de horas de facturación y tiempo a sus subcontratistas. El Director del programa estaba desanimado. "Nunca podremos conseguir eso en los contratos de los subcontratistas", decían. Afortunadamente estaba presente un miembro del departamento financiero. Esa persona respondió: "En el contrato de los subcontratistas hay una cláusula que les obliga a rellenar el parte de horas como queremos". Problema resuelto.

Con frecuencia suelo hablar de la idea de evitar el problema antes de llegar a la solución; no obstante, suele ser un idea difícil de adoptar. El pensamiento lógico tendría que dictar que el orden al determinar una solución automatizada sería:

  1. Identificar el problema

  2. Definir la solución

  3. Determinar si (y, si es así, cómo) automatizar la solución

Las demostraciones de soluciones automatizadas en sitios web, vídeos y en otros sitios nos hacen olvidar esto. No buscamos una solución a menos que exista algún tipo de problema, pero las soluciones automatizadas parecen y suenan tan convincentes que terminamos haciendo esto:

  1. Elegir la solución automatizada

  2. Conseguir que el problema implemente la solución

  3. Resolver ese problema definiendo cómo se puede aplicar la herramienta automatizada a la solución

  4. Intentar recordar cuál era el problema original

El nuevo problema se convierte en la implementación de la solución durante bastante tiempo y, después de semanas, meses o incluso un par de años en marcha, alguien del área ejecutiva pregunta cuándo se va a resolver el problema original y todo el mundo se mira sorprendido. Es fácil olvidar.

Con los años, he recomendado todo tipo de posibles soluciones automatizadas. 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 el uso de una combinación de Excel y Outlook. He recomendado el uso de hojas de partes de terceros con Project.

E incluso, una vez, recomendé el uso de una gran pizarra. De verdad. He trabajado durante muchos años con esa organización. La persona en cuestión trabajaba en una inmobiliaria y tuvo que renovar los alquileres a largo plazo en el sector inmobiliario. Cuando le pregunté cuál era el problema, se trataba claramente de un problema de programación. La persona había olvidado unos plazos 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 informes que se distribuyeron a varios ejecutivos para que no se olvidaran futuros plazos. "¿Cuántos usuarios deberían incluirse?", pregunté. "Solo yo", respondió. "¿Cuántos de estos proyectos serán simultáneos?", pregunté. "Siete u ocho", me respondió. "¿Y cuántos de estos hitos de plazos administra en cada proyecto?". "Es muy complicado. Hay cerca de media docena de plazos en cada uno", me dijo.

Ya tenía claro que no deberíamos instalar un gran sistema EPM centralizado para este hombre.

"¿Por qué no colocamos simplemente una gran pizarra en su despacho y usamos algunos marcadores de colores para los diferentes hitos?", pregunté. "Podría usar el azul para el primero, el verde para el segundo, el rojo para el último, etc.".

Tomó muchas notas, fascinado por el concepto. Dejé la empresa sabiendo que no había vendido ningún servicio ni producto ese día, pero que decepcionaría a la persona que no podía implementar el sistema que había previsto. De vuelta a casa, sonó el teléfono del coche. Era él. "¿Podría explicarme los diferentes colores en la pizarra?", me preguntó.

Averiguar cuáles son los problemas que estamos intentando resolver antes de diseñar la solución y antes de elegir la forma de automatizarlo, no solo permite ahorrar dinero. Puede ahorrar una enorme cantidad de tiempo dedicado a trabajar en elementos de la organización que no tenían un problema que tuviéramos que resolver en primer lugar.

Cuando los problemas que intenta resolver se pueden solucionar mejor con un software de administración de proyectos empresariales centralizado, no hay nada más que hacer, pero el enfoque que habrá obtenido al articular el problema le ayudará incluso ahí. El equipo de implementación puede crear indicadores de éxito que permitan que el proyecto se declare como un éxito cuando se hayan resuelto los problemas. ¿Centralizar o descentralizar? La Administración de proyectos empresariales puede lograrse con ambos.

Acerca del autor

Chris Vandersluis es presidente y fundador de la empresa HMS Software, establecida en Montreal, Canadá, un asociado certificado de Microsoft. Cuenta con unos estudios en Economía en la Universidad McGill y más de 30 años de experiencia en la automatización de sistemas de control de proyectos. Es miembro del Project Management Institute (PMI) y participó en la creación de las secciones de Microsoft Project Users Group (MPUG) en Montreal, Toronto y Quebec. Entre las publicaciones en las que ha escrito Chris, se encuentran Fortune, Heavy Construction News, Computing Canada Magazine y PMNetwork de PMI; también es columnista habitual en Project Times. Es profesor de Administración avanzada de proyectos en la Universidad McGill y a menudo es ponente en actos de asociaciones de administración de proyectos de Norteamérica y el resto del mundo. HMS Software es el proveedor del sistema de control para los proyectos de TimeControl y es asociado de la solución Microsoft Project desde 1995.

Puede ponerse en contacto con Chris Vandersluis por correo electrónico: chris.vandersluis@hms.ca

Si desea leer más artículos relacionados con EPM de Chris Vandersluis, consulte el sitio de orientación EPM de HMS (http://www.epmguidance.com/?page_id=39).

Ampliar sus conocimientos
Explorar los cursos
Obtener nuevas características primero
Únase a los participantes de Office Insider

¿Le ha sido útil esta información?

¡Gracias por sus comentarios!

Gracias por sus comentarios. Quizá le interese ponerse en contacto con uno de nuestros agentes de soporte de Office.

×