Caso: Usted es un profesional de la gestión de proyectos. Se gana la vida como Interim Project Manager, haciendo que los proyectos de sus clientes terminen en coste y plazo, utilizando los recursos de la organización ejecutora. Sus clientes son organizaciones proyectizadas. A usted le miden por cumplimiento de objetivos –no por “presentismo”–. Algunos le pagan incentivos si el proyecto termina antes de la fecha límite, a satisfacción de los interesados. Estos clientes están abiertos a que usted les proponga nuevas prácticas, métodos y herramientas aplicables a cualquier otro proyecto, acordes con los requisitos del trabajador del conocimiento de hoy día. Si le piden que recomiende una o varias aplicaciones móviles para gestionar proyectos, ¿qué les recomendaría?
Cuando a mi me hacen esa pregunta, yo no tengo dudas en responder algunas herramientas móviles que me han dado buen rendimiento para gestionar equipos de proyectos. Propongo gestionar conversaciones con Slack, tareas con Asana y documentos con Google Drive. Todas ellas funcionan de forma equivalente en la web y en el móvil. Para planificar y controlar las actividades yo uso Microsoft Project, pero no la uso de manera colaborativa. En las actividades de project scheduling no necesito aplicación móvil, creo que siempre preferiré trabajar desde mi ordenador: uso Microsoft Project para centralizar toda la programación y el registro de la información relevante, y cuando tengo que comunicar el seguimiento la uso para producir informes que guardo en Google Drive.
Sin embargo, de momento soy incapaz de recomendar una aplicación móvil para gestionar carteras de proyectos de forma integrada, atendiendo a las necesidades de los 10 roles de gestión de proyectos. Casi todas las herramientas de gestión corporativa de proyectos ya tienen versión para móvil, pero siempre como canal adicional complementario, no como canal principal. En mi post anterior ¿Se pueden Gestionar los Proyectos con el Móvil? he recibido respuestas aconsejándome usar aplicaciones móviles que yo creo que no sirven para gestionar profesionalmente la cartera de proyectos.
En este post quiero enunciar una serie de requisitos que a mi juicio debería cumplir una aplicación de project portfolio management móvil. Agradezco cualquier feedback por email pulsando el siguiente enlace: enviar correo con mi opinión
1) Estructura básica de la información
Las organizaciones proyectizadas deben organizar sus proyectos agrupándolos, si es posible, en portafolios y programas. Las organizaciones se organizan por departamentos (business units). Al responsable de una business unit le podemos llamar Functional Manager. Podemos generalizar que todo proyecto está liderado por una business unit.
Los programas y portafolios son agrupaciones de proyectos. Un proyecto puede pertenecer a cero o un programa (no a varios). Proyectos y programas pueden pertenecer a cero, uno o varios portafolios. Suele considerarse que los portafolios y los programas pertenecen a la organización (no suelen encuadrarse solo dentro de una business unit).
2) Dualidad Proyecto–Solicitud
Como expliqué en el post los 10 roles de gestión de proyectos, todo proyecto admite dos tipos de gestión: una desde el punto de vista de quien lo solicita (Requester), parecida para todos los que están en el lado de la gestión de la demanda (Requester, Stakeholder, Sponsor, Functional Manager y PMO); y otra visión de gestión para los que están del lado de la gestión del suministro (Project Manager, Program Manager, Portfolio Manager, Team Member y Resource Manager).
Desde el lado de la gestión de la demanda, los proyectos se proponen, y si se aprueban, se sigue con atención el progreso hasta que se cierran. Desde el lado de la gestión del suministro, se debe emplear toda la profundidad de gestión necesaria para hacer que los proyectos terminen cumpliendo los objetivos, lo que afortunadamente está muy bien estandarizado en la Guía del PMBOK®, del PMI®.
Es interesante que en esta guía se propone que los proyectos se gestionen desde que son ideas, no necesariamente después de que se aprueban (razón por la cual hay dos procesos en el grupo de inicio).
En la práctica, desde el lado de gestión de la demanda, un proyecto podría ser iniciado por un Requester o la PMO. El Project Manager asignado podrá invitar a otros Stakeholders, y registrará la información de gestión que será accedida en modo lectura por los roles de gestión de la demanda. También debe ser posible que un proyecto se inicie desde el lado de gestión del suministro, ya sea por parte de un Project Manager, un Program Manager o un Portfolio Manager, que posteriormente podrán invitar los roles de gestión de la demanda.
Aunque digamos que el Requester es el titular de la solicitud –Request–, y el Project Manager es el titular del proyecto, en realidad pueden ser dos vistas de la misma información. A un nivel más alto, debe haber un titular para cada programa –el Program Manager– y otro titular para cada portafolio –el Portfolio Manager–, que gestionen no solo la lista de proyectos componentes sino la información agregada del programa o portafolio, lo cual también está estandarizado en las correspondientes guías publicadas por el PMI®.
3) Acceso multi-rol
El verdadero valor de una aplicación de proyectos móvil, a mi entender, es que sea sencillo para los usuarios colaborar online, pero ofreciendo estrictamente la información que necesitan, según su rol.
Un usuario debe poder entrar en la aplicación desde su teléfono con uno o varios roles. Por ejemplo, Jose puede entrar como Project Manager y Team Member, así podrá gestionar sus proyectos y reportar horas y gastos en esos proyectos y en otros en los que también participe.
A lo mejor quiere entrar también como Stakeholder para controlar otro proyecto subcontratado desde alguno suyo (gestión de las adquisiciones).
Este tema de la gestión de las adquisiciones del proyecto es muy potente para fomentar la viralidad de este tipo de aplicación móvil. Muchos proyectos externalizan parte de los trabajos a otros contratistas, que a su vez pueden subcontratar a otros. Estas interrelaciones entre los proyectos son a veces tan complejas que cuesta mucho seguir la traza para ver el mapa global de un proyecto.
Como puede observarse en la figura, entre las entidades principales del modelo de datos se encontrarían los “proyectos en procurement”.
Un proyecto puede subcontratar a otros. A los roles Project Manager, Program Manager y Portfolio Manager les seria fácil navegar desde un proyecto a sus proyectos subcontratados. Si estos proyectos también se gestionan con la aplicación, aunque estos proyectos pertenezcan a otras organizaciones, ellos podrían ver la información de gestión actualizada accediendo con el rol de Stakehoder. Por defecto, los roles PM* deberían tener el rol de Stakeholder en los proyectos subcontratados. Esta relación de procurement entre proyectos es solo un tipo de relación posible, otros ejemplos: precedencia temporal, precedencia en financiación, riesgo compartido, etc.
4) Gestionar con Cuentas de Control
La Guía del PMBOK® define cuenta de control de la siguiente manera:
“Una cuenta de control es un punto de control administrativo donde se integran el alcance, el presupuesto, el coste real y el cronograma, y se comparan con el valor ganado para la medición del desempeño.”
En esta imagen puede verse cómo suele descomponerse un proyecto en cuentas de control, paquetes de trabajo, actividades y tareas:
Creo que una aplicación móvil de gestión de proyectos no debería gestionar toda la información de un proyecto hasta el más bajo nivel porque resultaría muy farragosa. Debería quedarse al nivel de cuenta de control e integrarse con otras herramientas:
- No debe llegar a nivel de tarea, debe integrarse con herramientas de gestión de tareas tipo Asana
- Tampoco debe llegar a nivel de actividad, debe integrarse con herramientas de scheduling como Microsoft Project
- Aunque hay herramientas que se proponen para gestionar EDTs y mantener la información a nivel de paquete de trabajo, personalmente prefiero mantener esta información en la herramienta de scheduling.
Para gestionar un proyecto desde el móvil, debería ser suficiente establecer las cuentas de control (unas 20-30 suelen ser suficientes para gobernar perfectamente un proyecto de tamaño medio-alto) y planificar y controlar a este detalle fechas, grados de avance, entregables, hitos, costes, líneas base, estado global, asignaciones, etc. Una cuenta de control especial (la cuenta de control cero) puede ser la tarea resumen del proyecto. Por vía de la integración con la herramienta de scheduling puede automatizarse la actualización de la información a nivel de cuenta de control bidireccionalmente.
Como puede observarse en la figura anterior, el elemento central de la información puede ser la cuenta de control. Un proyecto puede tener una o varias cuentas de control (por defecto, la tarea resumen). Una cuenta de control puede tener varios Deliverables y asignar trabajos a varios Team Members.
A nivel de cuenta de control se puede integrar la información de las actividades, las tareas y los requisitos, etc., aunque eso es preferible desde otras aplicaciones especializadas.
5) Integración con otras apps
Al ritmo que están evolucionando las aplicaciones móviles corporativas, con una lucha feroz entre los grandes actores Microsoft, Google y Facebook –y recientemente Amazon– por posicionarse en el mercado de las aplicaciones corporativas para el puesto de trabajo del trabajador del conocimiento, en este momento me parece implanteable una aplicación PPM móvil que pretenda cubrir todo el espectro de un PMIS. Me parece más recomendable que este tipo de aplicación se integre con otras.
- Desde el lado de gestión de la demanda, son frecuentes las herramientas de gestión de relaciones comerciales CRM especializadas, si bien muchas organizaciones utilizan herramientas de gestión de tareas como Trello. Para gestionar el ciclo de venta de un proyecto podría modelarse en qué fase se encuentra. Para un Requester, un proyecto puede estar en estado prospecto, propuesta, contratación, en progreso, cerrado, aplazado o rechazado. Toda esta información es muy fácil modelarla con fichas de Trello, véase un ejemplo en la siguiente imagen:
- Otra categoría de aplicaciones a integrar son aquellas especializadas en control de cambios. Trello podría ser también una solución sencilla y disponible en móvil para controlar de forma integrada las solicitudes y aprobaciones de cambios.
- Desde el lado de la gestión del suministro, como ya se ha comentado, las herramientas a integrar podrían ser las que aparecen en la figura de arriba. Para dar seguimiento a las tareas, pensemos que una actividad podría resolverse con n tareas asignables a Team Members. Yo suelo crear un workspace de Asana por proyecto y tengo proyectos de Asana o secciones para relacionar tareas de Asana con actividades de Microsoft Project. Para gestionar las conversaciones del proyecto, suelo crear un equipo en Slack con varios canales. Para gestionar los documentos el proyecto, uso Google Drive. Estas herramientas son fácilmente integrables a través de sus APIs, y también ofrecen URLs por canal, lista, tarea, carpeta, etc., pero no son las únicas que podrían integrarse para cubrir estas funciones.
El requisito aquí es que la app PPM móvil pueda integrarse, por proyecto, con la herramienta preferida dentro de las 6 categorías –CRM, CCM, Scheduling, Documents, Tasks, Communication–.
6) Interfaz Móvil
Las limitaciones de representación del móvil hacen inviable a día de hoy la visualización de informes ricos en gráficas. Algo tan típico como un diagrama Gantt, un diagrama de red, una curva S, una EDT, un histograma de recursos, una matriz RACI, etc., sería muy incómodo de visualizar en la pantalla del móvil. La usabilidad requerida en el móvil abre una nueva serie de requisitos, entre ellos:
- La aplicación móvil debe limitarse a menús y a datos, no debería ofrecer gráficas.
- Como los elementos a visualizar pueden crecer mucho es necesario plantear mecanismos de filtro y ordenación persistentes. Por ejemplo, una PMO puede ver todos los proyectos abiertos y cerrados de la organización, y esto podría ser una lista muy larga. Debería poderse filtrar la lista por el estado de los proyectos, y/o estado de las solicitudes, y/o business unit, portfafolio, programa, project manager, color semafórico, etc. La ordenación también es importante en el móvil: puede interesar ordenar según la prioridad subjetiva, el valor para la organización, el tamaño del proyecto, el rating de riesgo, etc. También son importantes las funciones de búsqueda.
- Debe ser una aplicación nativa iOS-Android para integrar fácilmente con otras aplicaciones móviles, y también para que la app móvil produzca notificaciones cuando hay comentarios o solicitudes de cambios de algún interesado, por ejemplo.
- Siempre hará falta un espejo de aplicación web, con funcionalidad adicional para informes, gráficas, carga de datos e integración con otras aplicaciones corporativas. El uso típico de la aplicación móvil debería ser para consultar información, y quizá actualizar o entrar datos breves. El trabajo intenso de planificar el proyecto y el seguimiendo de las actividades debería realizarse más cómodamente desde la web o integrando con una herramienta de planificación. Los usuarios podrán ver la información actualizada en sus móviles, pero si cambian algo –una fecha, un progreso, un color– esto debería poderse ver instantáneamente en un navegador web y también debería poder integrarse con la herramienta de scheduling.
En el móvil deberíamos ver la información actualizada vía web, aunque si cambiamos alguna fecha, progreso, etc., esto debería poder actualizarse vía web hacia la herramienta de planificación.
Por favor, envíanos tus opiniones por email
¡Muchas gracias!