El modelo de madurez del sistema de gestión de proyectos: notas del producto

Estas notas del producto forman parte de nuestra colección "Desde las trincheras". En ellas se describe cómo, a medida que las organizaciones maduran, pueden usar sus sistemas de administración de proyectos de forma más eficaz. Indican cómo podría resultar más eficaz para las empresas la elección de usar solo algunos aspectos de un nuevo sistema de gestión de proyectos, hasta donde les resulte cómodo, aunque se sientan tentadas a utilizar todas y cada una de las características disponibles. Como la empresa sigue madurando, acaba adoptando cierta experiencia en el uso de las características que necesita utilizar.

Para descargar la versión de Word de estas notas de producto, consulte El modelo de madurez del sistema de gestión de proyectos: notas del producto.

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

El modelo de madurez del sistema de gestión de proyectos

El modelo de madurez de gestión de proyectos (PMM, por sus siglas en inglés) es un tema candente en la actualidad. Oleadas de consultores se ganan la vida ayudando a las organizaciones a evaluar su "nivel de madurez de proyectos", lo que casi siempre se muestra jerárquicamente: mejor cuanta más madurez, peor cuanta menos. Los partidarios del concepto explican que el modelo PMM muestra las capacidades de gestión de proyectos de una organización. Existe todo un debate sobre cómo conseguir que las organizaciones sean más eficientes y no estoy seguro de que se llegue necesariamente a la eficiencia mediante le modelo de Madurez de gestión de proyectos. Pero ya hablaremos de ello otro día. Sea un defensor o un detractor del modelo PMM, hay otro tipo de modelo de madurez que hemos detectado en las organizaciones que utilizan sistemas de gestión de proyectos.

Cuando trabajamos con las organizaciones que implementan un sistema de gestión de proyectos, es muy frecuente descubrir que el deseo de la organización es conseguir las ventajas de todos y cada uno de los elementos del nuevo sistema que acaba de mostrar el proveedor. El cliente ve informes, pantallas, flujos de trabajo y funciones con las que solo podía soñar y se imagina un mundo donde todas las características funcionan perfectamente en su empresa, del mismo modo que lo hacían en la demostración de ventas. Por lo general, al cliente no le queda claro que los datos y la configuración de la demostración que acaba de presenciar estaban perfectamente desarrollados para sacar el máximo partido del producto. En el caso de Microsoft Project y Project Server, esto se puede extender más allá del producto e incluir toda una lista de tecnologías.

El cliente ve pantallas que se inician desde Windows SharePoint Services o formularios de Microsoft Office SharePoint Server. Ve características que incorporan Active Directory o SQL Server Reporting Services. Podría ver flujos de trabajo de BizTalk Server o Windows Workflow Foundation y pantallas de PerformancePoint. El flujo de datos podría seguir un guión gráfico o un escenario de casos de uso que facilita la comprensión de las posibles ventajas, pero conocer la tecnología subyacente resulta más difícil.

Cuando se llega a proporcionar la funcionalidad en la que el cliente está interesado, tenemos que moderar sus deseos para implementar todo lo que necesite de una vez con los pies sobre la tierra. El cliente necesita decidir cómo desea hacer negocios antes de que podamos considerar la configuración de este tipo de funcionalidad y si se puede entregar listo para usar, configurado o personalizado. Hay algunos clientes que insisten en desarrollar todos los aspectos de la funcionalidad que ha observado y están preparados para profundizar en ella y preparar el diseño, la formación, el aprendizaje y el desarrollo de dicha solución, así como para buscar el tiempo y el dinero necesarios para este desarrollo, pero las empresas así son excepciones.

Es mucho más común que el cliente decida implementar los aspectos del nuevo sistema de gestión de proyectos con los que ya se sienta cómodo. Como la organización va aprendiendo más y más sobre el sistema y los procesos empresariales subyacentes, se volverá más exigente con el sistema y madurará a medida que vaya progresando. Es una progresión natural.

Como el entendimiento del proceso de gestión de proyectos de la organización va evolucionando automáticamente, sus exigencias respecto a dicha automatización también evolucionan. Esta progresión natural es igual que la de los modelos de gestión de proyectos o madurez capacitiva. El conocimiento de la evolución de estas organizaciones nos ha convertido en agentes eficaces a la hora de redoblar nuestros esfuerzos para mejorar la eficiencia de una organización. Tendemos a centrarnos en las áreas del sistema de proyectos que sabemos que tendrán más oportunidades de adopción y de ofrecer un ROI en función de la madurez del sistema de proyectos de la organización. Evidentemente no hay dos organizaciones iguales, por lo que grabar este conocimiento a fuego no sería un buen plan. Es la progresión más probable basada en nuestra experiencia con otras empresas.

Según esta experiencia, la evolución natural del uso de un sistema de gestión de proyectos se clasifica en cinco áreas básicas, aunque el orden entre ellas ha variado en los últimos años a causa de la tecnología. Empecemos hablando de las cinco áreas básicas y al final del artículo revisaré algunos de los cambios experimentados durante los últimos años.

5 áreas principales de un sistema de administración de proyectos

1 - Planificación   . Casi siempre, la primera ola que encontramos es la planificación. Algunas organizaciones nunca llegan más allá. Crean un programa básico, preparan un diagrama de GANTT y, a continuación, lo colocan en la pared del equipo del proyecto. El personal hace referencia a esta placa a veces con nostalgia, recordando el estado del programa antes del inicio del proyecto.

Aunque estoy siendo un poco cruel con los que utilizan su caro software de gestión de proyectos para hacer diagramas de barras, lo cierto es que hacerlo tiene su valor. La creación de un programa organizado hace que los participantes del proyecto piensen sobre cómo realizar su tarea y es mucho más efectivo que no hacer nada o simplemente preparar un parte de horas.

2 - Seguimiento   . La siguiente fase de nuestra experiencia suele ser el seguimiento. Una organización que sea un poco más "madura" en el uso de su sistema de gestión de proyectos no solo planificará, sino que seguirá las programaciones que realice, avanzará y actualizará periódicamente su progreso, e incluso se interesará por las planificaciones proyectadas a medida que el plan avance. Para muchas organizaciones, ya resulta efectivo detenerse en este punto. Están pensando en su sistema de gestión de proyecto y están trabajando en el plan para actualizarlo periódicamente, incluso creando informes de utilidad para administración.

3 - Gestión de recursos   . Cuando se han llevado a cabo la planificación y la supervisión, las empresas suelen enfrentarse a problemas de gestión de recursos y buscan soluciones mediante el sistema de gestión de proyectos. Los recursos pueden tener muchos aspectos, como ya hemos indicado antes, pero en el nivel más básico, la asignación de recursos (asignar las tareas a los recursos) suele ser un gran paso, seguido del análisis de recursos de algún tipo.

4 - Gestión de costes   . La gestión de costes es la cuarta área típica y muchas organizaciones nunca llegan a ella. En un nivel básico, un buen inicio es disponer de un coste estimado dividido por fases, o mejor aún, por tareas. El seguimiento de los costes reales por hora o por dólares formará el siguiente nivel.

5 - Avanzados   . Pondré un quinto campo aquí para temas "avanzados", que podría incluir una gran variedad de temas que no hemos clasificado en otras categorías de momento. No es que no sean importantes, pero resulta que, al llegar a la quinta ola de evolución de una organización, las cosas se pueden hacer de varios modos distintos. Por lo tanto, voy a clasificar aquí el análisis de riesgos, el análisis de documentos y los flujos de trabajo automatizados. También hay áreas avanzadas en cada una de las otras cuatro áreas que habíamos comentado hasta ahora.

Cada uno de los elementos que hemos comentado hasta ahora se podría extender más allá, y de hecho lo hace a medida que la madurez del proyecto de una organización y su comprensión de los aspectos automatizados de su entorno de gestión de proyectos aumentan.

En la fase de Planificación, la progresión puede incluir programas integrados por varios proyectos con enlaces entre proyectos o la gestión de programas con varios subproyectos.

En el caso de Seguimiento, la organización suele avanzar de un simple progreso de finalización con porcentajes, que suele ser el seguimiento de datos de menor calidad, a la duración restante. También es posible que la tarea de Seguimiento se extienda a partes de horas que proporcionen el número exacto de horas trabajadas en el plan original por persona.

En el área de Recursos, se pasa de solo asignar las tareas a los recursos, a seguir el progreso de los recursos, por lo general con un parte de horas, y a buscar los aspectos más codiciados de las EPM, la Planificación capacitiva de recursos. En algunas organizaciones, también se pueden contar aquí las Cadenas críticas, que fusionan la información de recursos y programación en un algoritmo avanzado.

En el caso de Costes, en general se pasa de la creación de presupuestos básicos al seguimiento de los costes reales con horas y tiempo del presupuesto en contraste con la varianza real. Después, se llega al seguimiento del Valor ganado, tal y como sucede en los sectores de defensa o aeroespacial.

Hasta el área Avanzados tiene temas avanzados. Los más populares son los análisis de riesgo Montecarlo y la metodología de gestión de proyectos de integración (en particular en el sector de la TI).

Áreas básicas y avanzadas de un sistema de administración de proyectos

La mayoría de las organizaciones progresan con los cinco elementos básicos de la izquierda del gráfico que aparece arriba en el orden que hemos descrito antes de revisar las áreas avanzadas. Algunos opinan que su reto de gestión de proyectos particular subyace en centrarse en un elemento sobre los demás. Lo que es muy extraño y pocas veces tiene éxito es intentar ser más maduro de lo que se es.

Es muy común, por ejemplo, en el caso de una organización que aspire a la planificación capacitiva de recursos, que cuando se analizan las habilidades y la experiencia de la organización, se descubra que faltan los fundamentos para la creación de un sistema de planificación capacitiva de recursos. A menudo utilizo la capacidad de planificación como ejemplo del motivo por el que resulta tan importante conocer su situación en el modelo de madurez de los sistemas de gestión de proyectos. Según mi experiencia, es la ventaja sencilla más solicitada de los sistemas de EPM y, aún así, prácticamente la última que se puede proporcionar. Esto se debe a que la planificación capacitiva de recursos requiere que otros elementos estén en marcha primero. Para proporcionar los requisitos de recursos proyectados frente a su disponibilidad, necesitamos:

  • Planes de proyecto fiables

  • Proyectos supervisados con indicaciones de proceso precisas

  • Todas las tareas que se asignarán a los recursos

  • Una disponibilidad de recursos completa y precisa

  • La cuantificación y el seguimiento de las tareas que no son proyectos

  • Un cumplimiento completo por parte de los gestores de proyecto y de departamento del trabajo finalizado, el trabajo proyectado y los cambios en los recursos.

¡Vaya! No es una lista corta y la cultura corporativa que debe cumplir con un entorno como este suele necesitar una gestión de cambios a gran escala. Por lo tanto, volvemos al modelo de madurez de los sistemas de gestión de proyectos y los clientes pueden crear una hoja de ruta con aquello que necesiten cumplir.

Evidentemente, esta no es una lista exhaustiva. Podemos crear fácilmente una tercera columna y luego una cuarta, pero no lo he hecho aquí porque, a partir de este punto, la progresión general no resulta tan clara. Cada requisito de gestión de proyectos de la organización dictará su interés en avanzar hacia un área concreta.

Al principio del artículo prometí comentar algunos puntos que habían cambiado en los últimos años. El modelo que he descrito anteriormente ha permanecido vigente durante bastante tiempo, pero en los últimos dos años, los movimientos del sector de TI han dado un cambio importante en otra dirección a causa de la colaboración.

Hubo una vez en que la industria del software de gestión de proyectos se centraba en algoritmos. Todo derivaba de una hoja de ruta fundamental, pensábamos. Sin embargo, en los últimos años las cosas han cambiado. En primer lugar, la disponibilidad de las personas se ha mejorado gracias a Internet y a la tecnología móvil, por lo que es más sencillo crear proyectos de equipo y comunicarse con ellos. Esto ha contribuido a cambiar la formación de los equipos de gestión de proyectos. Anteriormente se podría haber pensado que los miembros de un equipo de proyecto debían ser personas de la empresa que trabajasen en pequeñas salas sin ventanas con escritorios dispuestos alrededor de un trazador enorme. Hoy en día pensamos en los miembros de un equipo de proyecto de cualquier parte de la organización.

Los miembros del equipo incluyen, claro está, a las personas que realizan la tarea, pero también podrían incluir al patrocinador ejecutivo, al departamento de gestión de recursos, los usuarios o el departamento de marketing. Ahora no resulta infrecuente que el equipo del proyecto se extienda hasta más allá de las paredes del edificio, más allá de la organización misma, e incluya subcontratistas, contratistas principales e incluso el cliente. Los subcontratistas no tienen por qué estar en la misma zona horaria o en el mismo país. Todo esto ha convertido a la comunicación en un factor de éxito clave para los proyectos de varios sectores.

Esto ha ocasionado que algunas organizaciones de industrias como I+D o TI, por ejemplo, consideren el modelo de madurez de los sistemas de gestión de proyectos de otro modo distinto:

Elementos reordenados de un sistema de administración de proyectos

El primer elemento de estas organizaciones es crear un plan de comunicaciones, que casi siempre se basa en tecnologías de colaboración como SharePoint Server. Estas organizaciones descubren que, desde una perspectiva centralizada, pueden obtener más beneficios de la colaboración y comunicación de su equipo de gestión de proyectos ampliado que con cualquier otra planificación centralizada. El meteórico ascenso de la popularidad de SharePoint Server es una prueba del deseo acumulado de la gente por trabajar juntos.

La progresión desde un plan de comunicaciones básico suele pasar a la gestión del documento: un documento que podría ser, por ejemplo, un programa de proyecto. Está comenzando a darle la vuelta al progreso de gestión de proyectos empresariales clásico, pero se puede comprobar lo atractiva que puede resultarle a algunas organizaciones. Aprenda a lidiar con contratos, documentos, correos electrónicos, reuniones y otro tipo de comunicación e incremente rápidamente la eficiencia. No aprenda cómo manejar las comunicaciones y podría caer en una pérdida de eficiencia grave.

Respecto a la administración de documentos, hay un corto paso hasta gestionar problemas y realizar gestiones de cambios (lo que en TI e I+D significa gestionar uno de los aspectos más peligrosos de un proyecto).

Sorprendentemente, lo siguiente son los partes de horas. De hecho, a veces aparece incluso antes. Cuando nuestra organización comenzó a trabajar en el sector de los partes de horas con nuestro producto TimeControl, sabíamos que las organizaciones que necesitaban partes de horas como los nuestros eran aquellas que ya disponían de procesos de planificación y seguimiento lo suficientemente maduros como para poder aprovecharlos. Puede imaginar nuestra sorpresa al descubrir que muchas empresas querían implementar una solución de parte de horas empresarial antes de implementar un sistema de gestión de proyectos empresariales. Al comprobar el resto de gestión de cambios de cada una, el motivo resulta claro. La mayoría de los usuarios adoptará un parte de horas a regañadientes, pero rápidamente. Que una organización de 1 000 personas acepte un sistema de partes de horas centralizado es cuestión de semanas. Conseguir que esos 1 000 usuarios acepten un sistema de gestión de proyectos centralizado puede costar de varios meses a un par de años. Por lo tanto, aunque la planificación centralizada no esté establecida, la organización puede obtener grandes ventajas de los partes de horas centralizados.

Por último, estas organizaciones centran su atención en el ejercicio de planificación central de proyectos. Esto no quiere decir que no se haya realizado una programación del proyecto hasta el momento, sino que no se ha centralizado lo suficiente.

Como ocurrió en el primer modelo de madurez de los sistemas de gestión de proyectos, cada uno de estos elementos puede albergar también distintos temas avanzados.

Los planes de comunicación suelen progresar a sistemas de comunicaciones más integrados que incluyen la mensajería instantánea, la integración con el correo electrónico y otras funciones.

La gestión de documentos suele progresar hasta la gestión de flujos de tareas y la integración con formularios.

La gestión de problemas suele evolucionar a la gestión de listas de todo tipo y un proceso de gestión de cambios integrado.

Los partes de horas evolucionan de partes de horas de tareas a enlaces con los departamentos de Finanzas, Pagos, RR. HH. y, finalmente, a enlaces que vuelven al sistema de gestión de proyectos empresariales para recopilar los datos de seguimiento auditables.

La planificación y la gestión de recursos tiende a evolucionar del mismo modo que mi modelo de madurez de los sistemas de gestión de proyectos clásico.

No hay un modo "correcto" de avanzar para utilizar un sistema de gestión de proyectos, como tampoco existe un modo "incorrecto". Como he dicho en las columnas anteriores, lo más importante es entender primero qué desea cumplir para ser más eficaz como organización y, a partir de ese punto, diseñar la solución para dicho reto. Lo importante es saber que se tienen los fundamentos de los elementos básicos antes de comenzar a construir estructuras más avanzadas. A veces me habrán oído decir que se necesita hacer un curso inicial de gestión de proyectos antes de poder doctorarse en esta misma disciplina.

Recuerde que el uso de un sistema de gestión de proyectos es solo un aspecto de una posible solución y que usted decide su grado de "madurez" en cada área para mejorar la eficacia de su gestión de proyectos.

Sobre el 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.

×