La mejor alternativa a Asana para una oficina de gestión de proyectos: siete tareas que debe cumplir

Cuándo una PMO se queda pequeña con Asana

Conviene ser preciso sobre en qué es buena Asana, porque una PMO que diagnostica mal el problema compra el reemplazo equivocado. Asana da a los equipos un lugar compartido para tareas, responsables, fechas, comentarios y archivos. Se aprende rápido, no requiere un administrador y la gente lo usa de forma voluntaria, lo que es un listón más alto que el que supera la mayoría del software empresarial. Para coordinar el trabajo dentro de un equipo, esas son las propiedades adecuadas, y una comparación capacidad por capacidad en la comparativa de FlexiProject y Asana expone dónde divergen de verdad las dos herramientas.

El punto de ruptura llega cuando cambia la propia producción de la PMO. Coordinar el trabajo responde a la pregunta de quién hace qué y para cuándo. Gobernar una cartera, que en la mayoría de las organizaciones es el rol central de la PMO, responde a preguntas distintas: si la organización financia las iniciativas correctas, si cada una sigue teniendo justificación, si el dinero y las personas comprometidas con ellas están disponibles, y qué decir a la dirección. Esas preguntas no son versiones más difíciles de la primera. Necesitan otros datos por debajo, y una herramienta construida en torno a tareas no los contiene.

La consecuencia es que la PMO se convierte en la capa de compensación. Cada capacidad que la herramienta no tiene la cubre una persona: alguien monta la vista de cartera, alguien nota el proyecto que se saltó su revisión, alguien concilia el presupuesto con el sistema de contabilidad. Nada de eso aparece como coste de licencia, por lo que suele funcionar durante años antes de que alguien lo cuente, y por eso un rastreador de tareas le falla a una PMO.

La semana antes de la revisión de cartera

La forma reconocible del problema es la semana anterior a la reunión de la dirección. Alguien abre treinta o cuarenta espacios de proyecto de uno en uno, copia un estado de uno y un porcentaje de otro y lo pega en una presentación que está desactualizada antes de que empiece la reunión. Los propios estados dependen de que los responsables de proyecto se acuerden de actualizarlos, así que la vista ejecutiva solo está tan al día como la última persona que la tocó.

Gobernanza que alguien tiene que vigilar a mano

La segunda mitad del trabajo es la aplicación. Una PMO no solo observa proyectos, los mantiene en un proceso: un caso de negocio antes de la financiación, una revisión antes de la siguiente fase, un cambio aprobado antes de que crezca el alcance. Los campos personalizados y las reglas de automatización pueden registrar que un punto de control ocurrió, pero nada evalúa si ya debería haber ocurrido, así que alguien tiene que notar el proyecto que pasó a ejecución sin un acta aprobada. En cinco proyectos eso es una conversación; en cuarenta, repartidos en varios departamentos, es un puesto administrativo a tiempo completo, y es lo primero que se abandona cuando la PMO está ocupada. Aparte desglosamos qué es un verdadero control del presupuesto del proyecto.

Qué debe hacer una alternativa a Asana para una PMO

Una vez que el diagnóstico está claro, la lista de requisitos se acorta. Estos siete criterios son los que separan un sistema de cartera de una herramienta de tareas con un panel encima, y cada uno se corresponde con algo que produce una PMO en lugar de con una categoría de funciones.

Juntos describen lo que un software para PMO tiene que cubrir antes de poder cargar con la gobernanza de cartera. El resto de este artículo los toma de uno en uno, en el orden en que una PMO los encuentra a lo largo de un año. También vemos qué buscar cuando se consideran apps como Asana.

Admisión: decidir qué proyectos entran

Lo primero de lo que una PMO es dueña es la decisión sobre qué entra en la cartera. En la mayoría de las organizaciones esa decisión se toma con una mezcla de estrategia, precedente y quien argumentó con más insistencia, y se defiende después y no antes. Una herramienta de tareas no tiene nada que ofrecer aquí, porque la admisión ocurre antes de que haya un proyecto que seguir.

FlexiProject lo resuelve con un módulo de puntuación de proyectos construido sobre el propio modelo de la organización. Defines los criterios que importan, sea el encaje con la estrategia, el retorno esperado, la exposición al riesgo o la disponibilidad de recursos, asignas pesos y estableces con qué precisión deben ser las respuestas. Las ideas se puntúan entonces sobre la misma base, y la PMO tiene una clasificación que puede poner ante un comité de dirección sin depender de la persuasión.

Dos detalles marcan la diferencia entre un modelo de puntuación que se usa y uno que se abandona. El primero es que cada pregunta de puntuación puede dirigirse a su propio grupo de evaluadores. Las preguntas sobre complejidad técnica van a los arquitectos, las de rentabilidad a control de gestión, las de exposición legal al departamento jurídico, y la puntuación final agrega varias opiniones informadas en lugar de una persona adivinando fuera de su área. El segundo es que la puntuación no se limita al inicio. Un proyecto puede reevaluarse durante la ejecución a medida que llega nueva información, lo que da a la PMO un mecanismo que suele faltarle: una forma estructurada de detener una iniciativa que ya no merece su presupuesto, antes de que consuma otros dos trimestres.

Informes de estado sin montar diapositivas

Informes diseñados una vez, al día desde entonces

FlexiProject divide esto en dos mecanismos. Las revisiones de proyecto automatizadas recogen el estado de los responsables de proyecto con una cadencia definida, así que la entrada llega sin una ronda de persecución. El generador de informes compone entonces la salida a partir de datos en vivo: cualquier informe puede diseñarse en un constructor y abarca proyectos, tareas, hitos, partidas de presupuesto, riesgos, entregables o cambios de plan, filtrados por los criterios que exija la pregunta.

El efecto práctico se ve con las peticiones puntuales. Cuando un miembro de la dirección pide cada proyecto por encima de cierto presupuesto cuyo hito se retrasó este trimestre, la respuesta actual suele ser una tarde de exportaciones desde varios sitios. Diseñada una vez en el constructor de informes, esa pregunta se convierte en un informe permanente disponible de inmediato con datos actuales, y la próxima vez que se pida no hay trabajo alguno. Una PMO que lleva un año haciendo esto tiene una biblioteca que cubre la mayor parte de lo que la dirección pide de forma rutinaria, que es la manera práctica de informar del estado de los proyectos de forma más eficaz sin añadir otra reunión.

Cuando la PMO deja de ser el cuello de botella de los informes

El segundo cambio es estructural. En la mayoría de las organizaciones cada departamento pide a la PMO su propio corte de los datos: finanzas quiere costes por categoría, proveedor y periodo, el departamento jurídico quiere los riesgos legales reunidos de toda la cartera, una división de producción quiere solo sus propios proyectos. Cada petición es un trabajo aparte, y la PMO se convierte en una cola.

Como los informes se diseñan en vez de compilarse, cada departamento puede tener su propio conjunto. La PMO los construye una vez y se mantienen disponibles con datos actuales, exportables a Excel para quien quiera seguir trabajando con las cifras. Finanzas lee sus propios informes, jurídico lee su propia lista de riesgos, y la PMO deja de arbitrar el acceso a información que no le pertenece.

Revisiones de cartera que van más allá de tres minutos por proyecto

La revisión de cartera es donde la gobernanza o sucede o se representa. Una reunión de dos horas que cubre cuarenta proyectos, quince de los cuales tienen problemas reales, da a cada proyecto tres minutos. Eso no es una revisión. Es un pase de diapositivas con quórum, y todos en la sala lo saben.

El mecanismo que lo arregla es la síntesis antes que el detalle. El software de cartera de proyectos presenta la cartera en una sola pantalla: estado de hitos, salud del proyecto, desviación de presupuesto, avance frente al plan. La dirección o el comité de dirección puede identificar en segundos qué proyectos necesitan una discusión seria, y esos proyectos reciben un formato más profundo con tiempo dedicado, mientras los que van según el plan pasan en un minuto. La reunión deja de ser una secuencia de informes y se convierte en una secuencia de decisiones, y como el módulo de revisiones de proyectos programa la cadencia y extrae el material de los propios proyectos, la preparación desaparece con ella.

Hitos de control y cambios de plan que dejan registro

Un plan aprobado en enero y un plan en vigor en junio rara vez son el mismo plan, y la diferencia entre una cartera gobernada y una que no lo está es si alguien puede decir cómo cambió. En una herramienta de tareas, el plan simplemente pasa a ser lo que es ahora mismo, y el razonamiento vive en el correo.

FlexiProject trata un cambio del plan como un objeto formal. Cualquier cambio significativo de fechas, presupuesto o alcance puede plantearse como una solicitud de cambio con una justificación de negocio, y la solicitud muestra el plan actual y el propuesto uno junto al otro, incluido en el diagrama de Gantt del módulo de cronograma del proyecto, de modo que quien decide puede ver el tamaño de lo que está aprobando en lugar de leer una descripción. La solicitud pasa entonces por una ruta de aprobación y, una vez aprobada, se convierte en la nueva versión del plan. Cada solicitud queda archivada, lo que significa que la PMO puede reconstruir años después cómo evolucionó un proyecto y por qué, que es justo lo que una auditoría o un ejercicio de lecciones aprendidas necesita y casi nunca tiene. Por separado explicamos cómo abordar la planificación de proyectos que el sistema mantiene solo.

La capacidad de recursos que la PMO puede defender

FlexiProject lo aborda como software de gestión de recursos: modela la disponibilidad por persona y por día, con vacaciones y ausencias incluidas, y señala cuándo la carga planificada supera lo que hay disponible en un periodo dado. Eso es lo que atrapa la situación conocida en que un especialista aparece a la vez en los planes de diez proyectos, cada plan razonable por sí mismo y la suma imposible. La carga es visible directamente desde el diagrama de Gantt, así que mover una tarea en el tiempo muestra el efecto sobre la capacidad de inmediato, lo que convierte la planificación en una simulación que el responsable de proyecto ejecuta antes de aprobar el plan.

Por encima del proyecto individual, la PMO obtiene una vista de todos los recursos de proyecto a lo largo de los próximos meses, desglosada por estructura organizativa. Esa vista es la que permite a la PMO dar una respuesta defendible a dos preguntas que se le hacen con regularidad y que suele responder por instinto: si comprometerse con la oportunidad que hay sobre la mesa y cuándo tiene que empezar la contratación para los compromisos ya adquiridos. Para una PMO en una organización cuyos ingresos dependen de los proyectos, esa vista es un instrumento comercial, no una comodidad de planificación.

Dinero y riesgo por encima del proyecto individual

Dos cosas son visibles a nivel de cartera e invisibles proyecto por proyecto. Ambas suelen ser responsabilidad de la PMO y ninguna cabe en una herramienta de tareas.

Desviación de presupuesto con previsión hasta la finalización

Un campo con un número de presupuesto no es gestión presupuestaria. Gestionar el presupuesto de un proyecto significa saber, por línea, qué se planificó, qué se ha gastado y qué se espera gastar aún antes de que el proyecto cierre. El módulo de presupuesto del proyecto muestra esos tres valores con la desviación resultante, en el lado del coste y del ingreso, así que para los proyectos que generan ingresos la PMO ve el resultado financiero previsto y no solo el gasto.

Un registro de riesgos que la cartera puede leer

El riesgo en una herramienta de tareas es una tarea con una etiqueta. En un sistema de cartera es un registro con valoraciones, responsables, planes de respuesta e historial, y tiene un nivel por encima del proyecto. El registro de riesgos de FlexiProject tiene un nivel de cartera: cada cartera tiene su propia pestaña de riesgos que reúne los riesgos de todos sus proyectos en un solo lugar.

Lo que eso saca a la luz es la duplicación. Tres responsables de proyecto gestionando de forma independiente el mismo riesgo de proveedor invierten el triple de esfuerzo y llegan a tres conclusiones distintas, y nadie lo ve porque cada registro está completo en sus propios términos. A nivel de cartera, ese riesgo recibe un responsable y una respuesta. Los informes de riesgos también funcionan en la otra dirección: un equipo que inicia un nuevo proyecto puede extraer los riesgos registrados en proyectos similares y arrancar desde la experiencia de la organización en vez de un registro vacío y una hora de imaginación. Igualmente mostramos cómo funciona la gestión de riesgos del proyecto en la práctica.

Llevar tu estándar de PMO, no el del proveedor

Un acta y una matriz de riesgos que encajan con lo que ya usas

El módulo de acta de constitución del proyecto se ensambla a partir de componentes sin programación, de modo que el documento refleja la disposición que la organización ya usa. Puede existir más de un estándar de acta al mismo tiempo: proyectos de desarrollo con campos relevantes para I+D, proyectos de marketing con diferenciadores de mercado y canales, proyectos de inversión con campos de tecnología y amortización, mientras un conjunto de campos corporativos se mantiene común a todos. No se obliga a los departamentos a un documento de compromiso que no encaja con ninguno, que es lo que suele matar la estandarización.

La matriz de riesgos funciona igual. Sus dimensiones se configuran durante la implantación, así que una organización que lleva años trabajando con una valoración de tres por tres no está obligada a cambiar a cinco por cinco porque sea lo que el software da por supuesto. Las actas se versionan y se aprueban electrónicamente, y parte de cada una se rellena sola a partir del cronograma y del registro de riesgos, de modo que el documento se mantiene coherente con los datos subyacentes en lugar de envejecer desde el día en que se firma.

Rutas de aprobación por área de trabajo

Las reglas de aprobación rara vez son uniformes en una organización, y casi nunca lo son en un grupo de empresas. FlexiProject permite rutas de aprobación dedicadas por área de trabajo: una ruta de aprobación de presupuesto separada en una división de producción, una ruta compartida donde compartir tiene sentido, una ruta corta para proyectos operativos y una más larga para los estratégicos. La PMO codifica las reglas que existen en lugar de negociarlas a la baja hasta una sola ruta que todos toleran.

Hay un beneficio secundario que los responsables de PMO notan en un año. Cuando el acta, las plantillas, las rutas de aprobación y los formatos de revisión viven todos en el sistema, la metodología deja de vivir en las cabezas de colegas con experiencia. Un nuevo miembro de la PMO aprende el estándar de la organización aprendiendo la herramienta, y la incorporación que antes llevaba meses se comprime considerablemente.

Despliegue: niveles de licencia, idiomas y despliegue

El primero es el modelo de licencias. El sistema de gestión de proyectos FlexiProject cobra el acceso por rol en lugar de por número de personas. La mayoría de los sistemas cobran una tarifa comparable para todos, lo que significa que la organización paga un puesto completo por personas que abren la herramienta para actualizar sus propias tareas y consultar un estado. Ofrece tres niveles ajustados al rol real: una licencia completa para responsables de proyecto, miembros de la PMO, patrocinadores y decisores, una licencia estándar para participantes activos que reportan avance y colaboran en tareas, y una licencia gratuita para personas que solo necesitan visibilidad de su propio trabajo. La PMO decide la combinación, que es lo que hace que cubrir a la organización más amplia sea proporcionado en lugar de una negociación presupuestaria.

El segundo es el idioma. La interfaz está disponible en 28 idiomas y la documentación de usuario en 11, lo que importa para una PMO en un grupo con filiales en varios países. Un estándar y un sistema, con cada persona trabajando en su propio idioma, suele ser la diferencia entre la adopción real y el uso cortés pero nulo en las ubicaciones más pequeñas.

El tercero es el despliegue. FlexiProject está disponible on-premises junto a la nube. Para organizaciones en sectores regulados, o con política interna sobre dónde residen los datos, eso no es una preferencia sino la condición para siquiera ser evaluado.

Cuándo esta no es la respuesta correcta para tu PMO

Una PMO que da soporte a tres o cuatro proyectos sin presupuesto formal y sin compromisos externos de fechas todavía no necesita gobernanza de cartera, e introducirla añadirá proceso sin añadir control. La recomendación honesta ahí es mantener la herramienta de tareas y volver a la pregunta cuando la cartera crezca.

Y si la tarea central de la PMO es modelar presupuestos de capital y prever recursos entre miles de personas en un contexto de inversión de capital fuertemente regulado, las plataformas de peso pesado construidas exactamente para eso justificarán su coste de implantación. El caso de FlexiProject es más fuerte donde la PMO necesita gobernanza, visibilidad de cartera e informes automatizados sin un proyecto de configuración de varios trimestres por delante.

Cómo verificarlo en dos semanas

Reconstruye tres proyectos reales, no de muestra. Coge un proyecto grande con dependencias, un proyecto operativo pequeño y uno que esté ahora mismo en apuros, con sus cronogramas, personas y presupuestos reales. La fricción que encuentres es la fricción que encontrarás cada semana, y sirve además de formación, porque quien aprende el sistema con sus propios proyectos retiene más que quien completa un ejercicio sobre datos inventados.

Luego ejecuta cuatro pruebas dirigidas a la propia producción de la PMO. Produce el informe que normalmente montas a mano y cronométralo. Celebra una revisión de cartera usando solo lo que hay en pantalla, sin una presentación preparada. Empuja un cambio de plan por una ruta de aprobación y comprueba que el registro posterior muestra qué cambió y quién lo aprobó. Asigna a una persona que ya esté comprometida en otro sitio y observa si el sistema te avisa antes de aprobar el plan. Una herramienta que maneje esas cuatro manejará el resto; una que las falle no se salvará con campos personalizados.

Preguntas frecuentes

¿Es Asana una herramienta de gestión de cartera de proyectos?

No en el sentido que una PMO necesita. Asana es gestión del trabajo construida en torno a tareas, proyectos y colaboración, con vistas de cartera y objetivos en sus niveles superiores. Esas vistas resumen la actividad de tareas en lugar de gobernar una cartera frente a estrategia, presupuesto y hitos de control, y dependen de que los responsables de proyecto mantengan los estados al día a mano. Un sistema de cartera dedicado lee el estado de la cartera a partir de los datos subyacentes.

¿Qué necesita una PMO que una herramienta de tareas no proporciona?

Siete cosas en la práctica: puntuación objetiva de admisión, informes que corren sobre datos en vivo, síntesis de cartera en una pantalla, hitos de control y control de cambios exigibles, capacidad en toda la organización, consolidación financiera y de riesgos por encima del proyecto, y un estándar configurable. Una herramienta de tareas puede aproximar algunas con campos personalizados, pero la aproximación la mantiene la PMO, no el sistema.

¿Pueden los responsables de proyecto seguir trabajando como ahora?

En gran medida, sí, y este es el principal determinante de si un despliegue tiene éxito. El cronograma está disponible como lista de tareas, diagrama de Gantt y tablero Kanban sobre los mismos datos, así que un responsable de proyecto que trabaja en un tablero puede seguir trabajando en un tablero mientras la capa de cartera se mantiene coherente. Lo que cambia es que el avance se reporta en las tareas y se consolida automáticamente, en lugar de teclearse como un porcentaje a nivel de fase.

¿Necesita toda la organización una licencia de pago?

No. Hay tres niveles de licencia disponibles, y el nivel gratuito cubre a las personas que necesitan visibilidad de su propio trabajo e información básica del proyecto. En la mayoría de las organizaciones eso es una gran parte de los usuarios, que es lo que mantiene el coste de cubrir al equipo más amplio proporcional a lo que esas personas obtienen de él.

¿Podemos conservar nuestra acta de constitución y matriz de riesgos actuales?

Sí, y vale la pena insistir en ello. El acta se construye a partir de componentes, con varios estándares de acta capaces de coexistir para distintos tipos de proyecto, y las dimensiones de la matriz de riesgos se configuran durante la implantación. Una PMO no tiene que abandonar una escala de valoración que la organización entiende para adoptar el sistema.

La búsqueda de la mejor alternativa a Asana para una oficina de gestión de proyectos suele empezar como una comparación de herramientas y se resuelve en una pregunta sobre la propia carga de trabajo de la PMO. Si la oficina pasa su mes reuniendo información que ya existe, vigilando hitos de control a mano y defendiendo decisiones de recursos por instinto, la capacidad que necesita no es un mejor tablero de tareas. Es una puntuación de admisión que pueda poner ante un comité, informes diseñados una vez y al día desde entonces, una cartera que pueda leer en segundos, cambios que dejen registro, una capacidad que pueda defender, y todo ello llevando el estándar que la organización ya afinó en lugar de la versión de un proveedor. La forma fiable de saber si esa es tu situación es tomar dos semanas, tres proyectos reales y el informe que temes montar, y ver cuánto de él produce el sistema sin ti.