El modelo de madurez del sistema de administración de proyectos
Este artículo forma parte de nuestra colección "From the Trenches". Describe cómo, a medida que las organizaciones maduran, pueden ser más eficaces en el uso de sus sistemas de administración de proyectos. Describen cómo puede ser más efectivo para las empresas optar por utilizar solo algunos aspectos de un nuevo sistema de administración de proyectos en un nivel en el que se sientan cómodas aunque se sientan tentadas a usar cada característica disponible. A medida que la empresa sigue madurando, puede adquirir conocimientos más avanzados en el uso de las características que necesitan utilizar.
Para ver más artículos, consulte las notas del producto "Desde las trincheras".
Modelo de madurez del sistema de administración de proyectos
El modelo de madurez de administración de proyectos (PMM) es un tema bastante frecuente en estos días. Hay oleadas de consultores que están ganando una buena vida ayudando a las organizaciones a evaluar su "nivel de madurez del proyecto", que se muestra casi siempre jerárquicamente con más madura siempre se muestra como mejor que menos madura. Los defensores del concepto dicen que el modelo PMM muestra las capacidades de una organización para administrar proyectos. Hay una conversación completa que se debe tener sobre cómo las organizaciones se vuelven más eficaces y no estoy seguro de que simplemente escalar el modelo de madurez de project management necesariamente te lleva allí. Pero ese es un tema para otro día. Tanto si es fan del modelo PMM como si no, hay otro tipo de modelo de madurez que he visto con organizaciones que usan sistemas de administración de proyectos.
Cuando trabajamos con organizaciones que implementan un sistema de administración de proyectos, es muy común descubrir que el deseo de la organización es aprovechar las ventajas de cada elemento del nuevo sistema que acaba de demostrar el proveedor. El cliente ve informes y pantallas, flujos de trabajo y funciones que solo ha soñado e imagina un mundo en el que toda esa funcionalidad funciona tan bien en su organización como lo hace en la demostración de ventas. Normalmente no está claro para el cliente que los datos de demostración y la configuración de demostración que se está demostrando se desarrollaron cuidadosamente con el fin de mostrar la mayor parte del producto como sea posible. En el caso de Microsoft Project y Project Server, esto puede extenderse mucho más allá del único producto para incluir toda la pila de tecnología.
El cliente ve pantallas que se inician desde Windows SharePoint Services o desde formularios de Microsoft Office SharePoint Server. Ven una funcionalidad que afecta a Active Directory o SQL Server Reporting Services. Es posible que vean el flujo de trabajo de BizTalk Server o Windows Workflow Foundation y las pantallas que proceden de PerformancePoint. El flujo de datos podría seguir un guión gráfico o un escenario de caso de uso que facilita la comprensión de las posibles ventajas, pero la comprensión de la tecnología subyacente es más difícil.
Cuando llegamos a entregar realmente la funcionalidad que el cliente está interesado, necesitamos moderar sus deseos de implementar todo a la vez con una comprobación de realidad. El cliente debe decidir cómo quiere hacer negocios antes de incluso considerar la posibilidad de configurar dicha funcionalidad y si se puede entregar de forma inmediata, con configuración o con esfuerzo de personalización. Hay algunos clientes que insisten en que implementan todos los aspectos de la funcionalidad que han previsto y están preparados para profundizar y realizar el diseño, la formación, el aprendizaje y el desarrollo de esa solución, así como encontrar la financiación en tiempo y dinero para implementarla, pero estas organizaciones son la excepción.
Lo que es mucho más común es que el cliente elija implementar los aspectos de su nuevo sistema de administración de proyectos al nivel con el que ya se siente cómodo. A medida que la organización se vuelve más conoceda tanto sobre el sistema como sobre los procesos empresariales subyacentes, exigirá más y más del sistema; cada vez más "madura" a medida que avanza. Es una progresión natural.
A medida que evoluciona la comprensión de la organización de un proceso de administración de proyectos que se puede automatizar, también evoluciona su demanda de esa automatización. Esta progresión natural es igual que los modelos de administración de proyectos o madurez de capacidad. Saber que las organizaciones probablemente evolucionarán a lo largo de estas rutas nos ha hecho muy eficaces a la hora de saber dónde poner nuestros esfuerzos en hacer que una organización sea eficaz. Tendemos a centrarnos en aquellas áreas del sistema de proyectos que sabemos que tienen una mejor oportunidad de adopción y de dar un retorno de la inversión dada la madurez del sistema del proyecto de la organización. Por supuesto, ninguna de las dos organizaciones es la misma, por lo que poner este conocimiento en una tableta no es un buen plan. Es simplemente la progresión más probable en función de nuestra experiencia con muchas empresas.
En nuestra experiencia, la evolución natural del uso de un sistema de gestión de proyectos se encuentra en cinco áreas básicas, aunque la secuenciación de los mismos se ha desplazado en los últimos años gracias en gran parte a la tecnología. Vamos a hablar de las cinco áreas básicas con las que empezar, y trataré algunos de los nuevos turnos que hemos visto en los últimos años más cerca del final de este artículo.
1 - Planificación. Casi siempre vemos la planificación como la primera ola. Algunas organizaciones nunca van más allá de esto. Hacen una programación básica, broncean el gráfico de GANTT y, a continuación, lo montan en la pared de la oficina del equipo del proyecto. Personas hacer referencia a la placa de vez en cuando de forma nostálgica, ya que recuerdan el buen estado de su programación justo antes de que comenzara el proyecto.
Aunque estoy siendo un poco cruel con aquellos que solo usan su costoso software de administración de proyectos para crear un gráfico de barras, ciertamente hay valor al hacerlo. La creación de una programación organizada tiende a hacer que los participantes del proyecto piensen en cómo se debe armar el trabajo y es mucho más eficaz que no hacer nada o simplemente hacer una lista de hojas de cálculo.
2 - Seguimiento. Lo siguiente en línea en nuestra experiencia suele ser el seguimiento. Una organización un poco más "madura" en el uso de su sistema de administración de proyectos no solo planeará, sino que realizará un seguimiento de sus programaciones, las avanzará periódicamente con el progreso hasta la fecha e incluso esperará las programaciones proyectadas a medida que avancen los planes. Para muchas organizaciones, detener aquí es eficaz. Están planeando en su sistema de administración de proyectos y, a continuación, están trabajando el plan actualizándolo periódicamente e incluso proporcionando informes útiles a la administración.
3: Administración de recursos. Una vez que se controlan el planeamiento y el seguimiento, las organizaciones tienden a examinar el problema de administración de recursos y cómo podría resolverse mediante el sistema de administración de proyectos. Los recursos pueden tener muchos aspectos, como he comentado aquí antes, pero en el nivel más básico, la asignación de recursos (asignar el trabajo a los recursos) es un gran paso, seguido de un análisis de recursos de algún tipo.
4 - Cost Management. La administración de costos es el cuarto área típica y muchas organizaciones nunca llega aquí. En un nivel básico, tener una estimación de costos desglosada por fase o mejor aún por tarea en el proyecto es un buen comienzo de cálculo del coste. El seguimiento de los costos reales por horas o por dólares es el siguiente nivel.
5 - Avanzado. Voy a poner una quinta área aquí para temas "Avanzados" para lo que podría ser una amplia gama de temas que no he puesto en las otras categorías hasta ahora. No es que no sean importantes, pero cuando llegas a la quinta ola de evolución de una organización, puede ir de muchas maneras diferentes. Por lo tanto, colocaré el análisis de riesgos, la administración de documentos y los flujos de trabajo automatizados aquí. También hay áreas avanzadas en cada una de las otras cuatro áreas que he analizado hasta ahora.
Cada uno de los elementos que he analizado hasta ahora podría ampliarse aún más y a menudo es a medida que aumenta la madurez del proyecto de la organización y la comprensión del aspecto automatizado de su entorno de administración de proyectos.
En Planeamiento, la progresión puede ir a programaciones integradas de varios proyectos con vínculos entre proyectos o administración de programas con subproyectos.
En el caso del seguimiento, la organización suele avanzar desde un simple porcentaje de progreso completo, que suele ser la calidad más baja de los datos de seguimiento, hasta la duración restante. El seguimiento también puede extenderse a partes de horas para proporcionar un valor exacto de horas trabajadas en el plan original por persona.
En el área Recursos, vemos que pasa de asignar simplemente las tareas a los recursos a realizar un seguimiento del progreso de los recursos normalmente con un parte de horas y, a continuación, pasar al aspecto más solicitado de EPM, Planeamiento de capacidad de recursos. Para algunas organizaciones, Critical Chain también encaja aquí, combinando la información de recursos y programación en un algoritmo avanzado.
En el caso de los costos, normalmente pasamos de la presupuestación básica al seguimiento de los costos reales, junto con horas y tiempo para obtener presupuesto frente a varianza real, y de ahí al seguimiento del valor obtenido, como se hace en los sectores de defensa y aeroespacial.
Incluso el área Avanzadas tiene temas avanzados. Los más populares entre ellos son El análisis de riesgos de Monte Carlo y la integración de la metodología de gestión de proyectos (especialmente en el sector de TI).
La mayoría de las organizaciones progresan con los cinco elementos básicos del lado izquierdo del gráfico anterior en el orden que acabo de describir antes de pasar a cualquiera de las áreas avanzadas. Algunos consideran que su desafío particular de administración de proyectos significa centrarse en un elemento por delante de otros. Lo que es extremadamente difícil y rara vez exitoso es tratar de ser más maduro de lo que eres.
Es muy común, por ejemplo, que una organización desee el planeamiento de la capacidad de recursos, pero cuando se examinan las aptitudes y la experiencia de la organización, se detecta que faltan los bloques de creación de la creación de un sistema de planeamiento de capacidad de recursos. A menudo uso el planeamiento de capacidad como ejemplo de por qué es tan importante saber dónde se encuentra en el modelo de madurez de sistemas de administración de proyectos. En mi experiencia, este es el único beneficio más solicitado de los sistemas EPM y, sin embargo, es casi la última ventaja que puedo ofrecer. Esto se debe a que la planeación de la capacidad de recursos requiere tantos otros elementos para trabajar primero. Para ofrecer los requisitos de recursos proyectados frente a la disponibilidad, primero necesitamos:
Planes de proyecto en los que podemos contar
Seguimiento de proyectos con un progreso preciso
Todas las tareas que se van a asignar a los recursos
Disponibilidad de recursos completa y precisa
Todo el trabajo que no sea de proyecto que se va a cuantificar y realizar un seguimiento
Complete el cumplimiento por parte de los jefes de proyecto y de departamento sobre el trabajo completado, el trabajo proyectado y los cambios en los recursos.
¡Qué bien! No es una lista pequeña y la cultura corporativa necesaria para cumplir con este tipo de entorno a menudo requiere administración de cambios a gran escala. Por lo tanto, volvemos al modelo de madurez de los sistemas de administración de proyectos y los clientes pueden hacer una hoja de ruta de lo que necesitan lograr.
Por supuesto, esta no es una lista exhaustiva. Podemos hacer fácilmente una tercera columna y luego una cuarta, pero no lo he hecho aquí porque desde este punto la progresión más común es menos clara. Los requisitos de administración de proyectos de cada organización determinarán el interés en avanzar en un área determinada.
Me prometí anteriormente en el artículo para discutir algo que ha cambiado en los últimos años. El modelo que he descrito anteriormente se ha mantenido durante bastante tiempo, pero en los últimos dos años, el movimiento en el sector de TI ha hecho un cambio significativo en otra dirección, y eso tiene todo que ver con la colaboración.
En un momento dado en la industria del software de administración de proyectos estábamos muy centrados en algoritmos. Todo surgió de la programación de ruta crítica, pensamos. Sin embargo, en los últimos años, algunas cosas han cambiado. En primer lugar, la disponibilidad de las personas a través de la omnipresente tecnología de Internet o teléfono ha hecho que sea aún más fácil ensamblar y comunicarse con el equipo del proyecto. Esto ha ayudado a cambiar quién está en un equipo de administración de proyectos. Aunque una vez hubiéramos pensado que los miembros del equipo del proyecto eran personas de la organización, que trabajaban en una pequeña sala sin ventanas con escritorios alrededor de un trazador masivo, ahora pensamos en los miembros del equipo del proyecto en toda la organización.
Los miembros del equipo incluyen aquellos que realizan el trabajo, por supuesto, pero también pueden incluir el patrocinador ejecutivo, los administradores de recursos del departamento, los usuarios y el departamento de marketing. Ahora no es nada raro encontrar que el equipo del proyecto se extiende no sólo más allá de las paredes del edificio, sino bien fuera de la propia organización para incluir subcontratistas, contratistas primos e incluso el cliente. Es posible que los subcontratistas no estén en la misma zona horaria o incluso en el mismo país o región. Todo esto ha hecho de la comunicación un factor de éxito clave para proyectos en muchos tipos diferentes de industrias.
Esto ha provocado que algunas organizaciones de sectores como R&D y TI, por ejemplo, examinen un modelo de madurez de sistemas de administración de proyectos que progresa de manera muy diferente:
El primer elemento de estas organizaciones es crear un plan de comunicaciones, que casi siempre se basa en la tecnología de colaboración como SharePoint Server. Estas organizaciones encuentran que, desde una perspectiva centralizada, pueden obtener más ventajas de conseguir que su equipo de administración de proyectos extendidos colabore y se comunique que desde cualquier planeamiento centralizado. El meteórico aumento de la popularidad de SharePoint Server es un testimonio de cuánto deseo se acumula para que las personas trabajen juntos.
La progresión de un plan básico de comunicaciones suele ir a la administración de documentos, un documento del que podría ser una programación de proyecto. Está cambiando el progreso de la administración de proyectos empresariales clásico en su cabeza, pero puede ver para algunas organizaciones lo atractivo que podría ser esto. Obtener un control sobre los contratos, documentos, correos electrónicos, reuniones y otras comunicaciones, y la eficiencia aumenta muy rápidamente. No controle las comunicaciones y la pérdida de eficiencia podría ser grave.
Desde la administración de documentos, se trata de un breve paso para administrar problemas y realizar la administración de cambios, lo que para TI y R&D significa administrar uno de los aspectos más potencialmente perjudiciales de un proyecto.
Sorprendentemente, los parte de horas vienen a continuación. De hecho, a veces los partes de horas vienen incluso antes. Cuando nuestra organización comenzó por primera vez en el negocio del parte de horas con nuestro producto TimeControl, estábamos muy seguros de que las organizaciones que necesitaban un parte de horas como la nuestra eran aquellas que ya eran lo suficientemente maduras en su proceso de planeamiento y seguimiento para poder aprovecharlo. Puede imaginar nuestra sorpresa al descubrir que muchas organizaciones quieren implementar un parte de horas empresarial antes de implementar un sistema de administración de proyectos empresariales. Al examinar el desafío de administración de cambios de cada uno, queda claro por qué. La mayoría de los usuarios adoptarán un parte de horas con rencor, pero rápidamente. Conseguir que una organización de 1000 personas acepte un sistema centralizado de parte de horas tarda unas semanas. Conseguir que los mismos 1000 usuarios acepten un sistema centralizado de administración de proyectos puede tardar de meses a un par de años. Por lo tanto, aunque no se haya establecido el planeamiento centralizado, la organización todavía puede beneficiarse enormemente de los datos centralizados del parte de horas.
Por último, estas organizaciones vuelven su atención al ejercicio básico de planeamiento de proyectos. Esto no quiere decir que no hayan estado realizando la programación de proyectos hasta ahora, pero no habrá sido muy centralizada.
Al igual que el primer modelo de madurez de sistemas de administración de proyectos, cada uno de estos elementos también puede llevar temas avanzados.
Los planes de comunicaciones suelen avanzar a sistemas de comunicaciones más integrados, como mensajería instantánea, integración de correo electrónico y mucho más.
La administración de documentos suele avanzar a la administración de flujos de trabajo y a la integración de formularios.
La administración de problemas suele evolucionar a la administración de listas de todo tipo y a un proceso de administración de cambios integrado.
Los parte de horas evolucionan de los parte de horas de las tareas a los vínculos con Finanzas, Nómina, RR. HH. y, en última instancia, se vinculan al sistema de administración de proyectos empresariales para obtener datos de seguimiento auditables.
La planificación y la administración de recursos tienden a evolucionar igual que mi modelo clásico de madurez de sistemas de administración de proyectos.
No hay ninguna manera "correcta" de avanzar en el uso del sistema de administración de proyectos, ni hay una manera "incorrecta". Como he dicho anteriormente en estas columnas, lo más importante es que examine primero lo que necesita lograr para ser más eficaz como organización y, a partir de ahí, diseñar la solución a ese desafío. Lo importante es saber que tiene los bloques de creación de los elementos básicos antes de empezar a crear algo más avanzado. A menudo me dicen que necesitamos Project Management 101 antes de pasar a los doctorados de Project Management.
Recuerde que el uso de un sistema de gestión de proyectos es solo un aspecto de una posible solución y depende de usted decidir qué tan "madura" debe ser y en qué áreas para que la gestión de sus proyectos sea más eficaz.
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).