Alternativa a Asana para la gestión de riesgos del proyecto: un registro que no es una lista
Asana ofrece una plantilla de registro de riesgos y una plantilla de matriz de riesgos. Allí puedes registrar una amenaza, valorarla y asignarle un responsable. El problema está en otra parte. Ese registro es un proyecto corriente hecho de tareas con algunos campos añadidos, no un módulo aparte del sistema. Con los primeros riesgos no supone diferencia. Empieza a importar cuando tienes veinte riesgos, varios proyectos, y alguien pregunta si otro equipo ya está gestionando la misma amenaza. Este artículo muestra lo que una lista así no puede hacer y describe los mecanismos que cierran la brecha.
Puntos clave:
- Una plantilla de registro es una lista de tareas corriente. Un riesgo registrado como tarea no puede vincularse a otra tarea ni compararse con riesgos de tus otros proyectos.
- La matriz de riesgos tiene que usar la escala con la que ya trabajas. Una empresa que usa una escala de tres por tres no cambiará a cinco por cinco. El módulo quedará vacío.
- Vincular un riesgo a una tarea cambia la forma de trabajar. Después de mover el cronograma, ves enseguida qué amenazas se han vuelto urgentes.
- El riesgo debería ser conocimiento de toda la organización. Las plantillas con riesgos típicos y las fichas de cierre dan al equipo un punto de partida en lugar de una lista vacía.
- El mayor ahorro es el fin de la reescritura. El acta de constitución del proyecto y el informe mensual toman los riesgos del registro automáticamente.
Un registro de riesgos que es una lista de tareas
Asana tiene una plantilla lista de registro de riesgos y una de matriz. Su lógica es correcta: describes la amenaza, valoras su probabilidad e impacto, nombras un responsable y añades un plan de respuesta. Con un proyecto y una docena de riesgos basta. También supera a una hoja de cálculo, porque el registro está donde ocurre el trabajo, y una comparación funcionalidad por funcionalidad de FlexiProject y Asana traza el panorama más amplio.
La limitación está en la construcción. Aquí un riesgo no es un objeto aparte, solo una tarea con campos extra. Todo lo que se sigue de que un riesgo no sea trabajo por hacer hay que organizarlo fuera de la herramienta.
Lo que la plantilla te da y lo que no puede
La plantilla ordena la información, y ese es su valor real. Tres cosas no te las da.
Un riesgo no puede apuntar a otra tarea, porque él mismo es una tarea. Así que no puedes registrar que una amenaza dada concierne a una entrega concreta del cronograma. Los riesgos tampoco pueden compararse entre proyectos, porque los campos propios funcionan solo dentro de un proyecto. Y no hay un nivel por encima del proyecto. Cada registro es completo en sí mismo y ciego a lo que tiene al lado. Tres equipos pueden estar gestionando el mismo riesgo de proveedor y ninguno de ellos se enterará.
Tres señales de que el registro ha dejado de funcionar
Un registro que se actualiza justo antes del comité de dirección en vez de a medida que avanza el trabajo. Si actualizar es una actividad aparte, ocurre cuando alguien la pide. Normalmente demasiado tarde para cambiar nada.
Riesgos reescritos a mano en el acta de constitución del proyecto y en el informe mensual. Ese trabajo no crea información nueva, y acaban circulando por la empresa tres versiones de la misma lista.
La pregunta „¿ya lo está gestionando alguien?» sin nadie a quien preguntar. Sin un nivel donde se encuentren los riesgos de distintos proyectos, cada uno se resuelve desde cero. También vemos qué buscar cuando se consideran apps como Asana.
Qué exigir a un registro de riesgos
La diferencia entre una lista y un módulo se reduce a siete cosas. Cada una la resuelve el sistema o se hace a mano.
| Requisito | Qué se rompe sin él |
| El riesgo como objeto aparte | No puedes vincularlo a una tarea ni distinguirlo del trabajo por hacer |
| Una matriz configurable | El sistema impone una escala que no usas, y el módulo se abandona |
| Un vínculo con el cronograma | Tras mover una fecha, no ves qué riesgos se han vuelto urgentes |
| Categorías compartidas en toda la organización | No puedes reunir riesgos legales o tecnológicos de varios proyectos |
| Un nivel de cartera | Varias personas trabajan en paralelo sobre la misma amenaza |
| Una base de conocimiento de riesgos | Cada equipo identifica riesgos desde cero y la experiencia de la empresa se pierde |
| Rellenado automático de documentos | El acta y el informe hay que rellenarlos a mano |
Juntos describen lo que un software de gestión de riesgos tiene que ofrecer. A continuación recorro los requisitos uno a uno y muestro cómo los resuelve FlexiProject.
Identifica, controla, monitoriza y gestiona los riesgos del proyecto, prueba FlexiProject gratis 30 días.
Una matriz en las dimensiones que ya usas
Configurar la matriz de riesgos parece un detalle. Es una de las razones más comunes de que un módulo de riesgos en un sistema PPM quede vacío. Una empresa dedicó años a desarrollar una matriz de tres por tres, y el sistema que se implanta trae cinco por cinco codificado a fuego. Nadie va a reeducar a treinta jefes de proyecto en una escala nueva porque un proveedor lo decidiera. El resultado es previsible: el módulo queda sin usar y el riesgo vuelve a una diapositiva.
En FlexiProject las dimensiones de la matriz se fijan durante la implantación, sin programar. La empresa aporta la escala que su gente conoce, junto con la costumbre de que una valoración dada exige una respuesta dada. El estándar que desarrollaste sobrevive así al cambio de herramienta.
Una ficha de riesgo en lugar de una fila en una tabla
En el sistema de gestión de proyectos FlexiProject el registro de riesgos es un módulo aparte del proyecto. Cada riesgo tiene nombre, estado, responsable, un vínculo con una tarea del cronograma, una categoría, impacto, probabilidad y fecha de identificación. El impacto en el cronograma y el impacto en el presupuesto se valoran por separado. Eso importa en la práctica: un riesgo que retrasa la aceptación un mes y un riesgo que suma cien mil al coste piden respuestas distintas. Una valoración común de „impacto alto» no los distinguirá.
Por encima del registro está una ficha de riesgo. Además de los datos del registro, guarda adjuntos, el plan de gestión de esa amenaza y un mensajero donde el equipo comenta ese riesgo concreto. Parece una nimiedad, pero resuelve un problema real. Una discusión en un canal de equipo desaparece en dos días. Una conversación registrada en el riesgo se queda con él. Cuando alguien pregunta seis meses después por qué se eligió esa respuesta, la respuesta está en el mismo sitio que la decisión.
Riesgo anclado a una tarea del cronograma
Los registros de riesgos suelen ser planos. Tratan un riesgo que afecta a todo el proyecto, por ejemplo una escasez de recursos, igual que un riesgo que afecta a una sola tarea, como una entrega de un subcontratista. Son dos situaciones distintas y se gestionan de forma distinta.
En FlexiProject cada riesgo puede vincularse a una tarea concreta del módulo de cronograma del proyecto. Asignas un riesgo de proveedor a la tarea que depende de la entrega, y un riesgo regulatorio a la tarea de aprobación. A partir de ahí el cronograma lleva información sobre amenazas. En la línea de la tarea aparece un triángulo con un signo de exclamación, y a su lado un círculo: rojo cuando el riesgo está activo, gris cuando no. El jefe de proyecto ve los puntos que necesitan atención sin abrir el registro.
Esto ayuda sobre todo cuando el plan cambia. Cuando el cronograma se mueve, sabes enseguida qué riesgos se han vuelto más apremiantes. Afectan a tareas que se han acercado a una fecha límite dura o han pasado a la ruta crítica. Esa información también existe en un registro plano, pero tienes que deducirla tú comparando dos listas. Así que normalmente nadie lo hace. Por separado explicamos cómo abordar la planificación de proyectos que el sistema mantiene solo.
El riesgo como conocimiento de la organización, no de un proyecto
En la mayoría de las empresas la forma en que los equipos identifican y evalúan los riesgos del proyecto se reduce a una reunión de arranque donde alguien imagina qué podría salir mal. El método es poco fiable. Las personas subestiman amenazas que no han encontrado antes. La empresa en su conjunto suele haberlas visto ya, solo que en otro proyecto.
Plantillas con una lista de riesgos típicos
Una lista de riesgos potenciales para un tipo de proyecto dado puede incorporarse a la plantilla. Un equipo que arranca una implantación para cliente, un proyecto de investigación o una inversión empieza con una base lista y la ajusta a su caso. Esto cambia la naturaleza de la reunión. En lugar de inventar amenazas, el equipo revisa las conocidas y decide cuáles aplican. Es más rápido y más eficaz, sobre todo en equipos menos experimentados.
La ficha de cierre y los informes de riesgos
La otra cara de este mecanismo es registrar lo que realmente ocurrió. La ficha de cierre del proyecto puede enumerar los riesgos que se materializaron y cómo se resolvieron. Los equipos que planifican proyectos posteriores tienen acceso a fichas de cierre históricas.
El tercer elemento son los informes. En el módulo de informes puedes construir una vista de riesgos para los proyectos de una categoría o de un área de la organización. Un equipo nuevo obtiene una respuesta concreta: estas son las amenazas que se materializaron en proyectos similares. Juntos, estos tres mecanismos hacen que la gestión de riesgos deje de depender de la competencia de un solo responsable.
Gestiona los riesgos del proyecto con eficacia con registro de riesgos y planes de acción, empieza gratis hoy con FlexiProject.
Categorías de riesgos y la vista para los departamentos
El riesgo rara vez concierne solo al jefe de proyecto. Legal quiere saber qué obligaciones y disputas hay en la cartera. Producción pregunta por los retos tecnológicos, compras por las amenazas del lado de los proveedores. Con un registro encerrado dentro de un proyecto, ninguno de ellos puede plantear su pregunta.
En los ajustes de FlexiProject defines tu propia lista de categorías de riesgo, acorde con cómo se reparte la responsabilidad en la empresa. Aquí una estructura de desglose de riesgos (RBS) deja de ser un diagrama y se convierte en algo por lo que el sistema puede filtrar. Sobre eso se construyen los informes entre proyectos. Legal ve los riesgos legales de todos los proyectos, producción los suyos, compras los suyos. El riesgo deja de ser asunto privado del jefe de proyecto. Aparte desglosamos qué es un verdadero control del presupuesto del proyecto.
Nivel de cartera, o el fin de gestionar el mismo riesgo tres veces
Con varias decenas de proyectos, algunas amenazas se repiten por su naturaleza. El mismo proveedor, el mismo cambio normativo, la misma tecnología inmadura. Si los registros están encerrados dentro de los proyectos, cada responsable mantiene su propia versión de ese riesgo y llega a conclusiones ligeramente distintas.
El software de cartera de proyectos lo resuelve de otro modo. Cada cartera en FlexiProject tiene una pestaña de riesgos aparte. Reúne las amenazas de todos los proyectos de esa cartera. El coordinador ve la repetición y puede resolver el riesgo de forma centralizada, con todo el conocimiento disponible en lugar de una sola perspectiva. El triple esfuerzo se convierte en un responsable y una respuesta. También elimina la situación en la que tres proyectos aplican tres estrategias distintas al mismo proveedor. Aparte explicamos qué debe ofrecer una alternativa a Asana para una PMO.
Se acabó la reescritura: el acta y el informe de estado
El ahorro más visible tiene que ver con la reescritura, no con el análisis. En muchas empresas el procedimiento exige que los riesgos más significativos lleguen al acta de constitución del proyecto y, una vez al mes, al informe para la dirección. Con un registro aparte, alguien mueve las mismas entradas a dos sitios y comprueba que las versiones coinciden.
En FlexiProject el módulo de acta de constitución del proyecto toma los riesgos del registro automáticamente. Ambos documentos son coherentes por diseño, no por la diligencia de nadie. El reporte de estado cíclico funciona igual. Si el informe contiene una sección de riesgos, se rellena solo desde el registro, y al responsable le queda un comentario sobre cómo se están gestionando esas amenazas. Una actividad que no creaba información nueva desaparece, y desapareció de la peor semana del mes.
Cuándo basta con una plantilla
¿Llevas un proyecto, lo gestionas tú, tienes una docena de riesgos y nadie exige informes formales? Una plantilla de registro en una herramienta de tareas basta. Un módulo aparte añadirá formalidad, no control, porque los problemas descritos arriba aparecen a mayor escala. Si quieres una mirada más amplia a las opciones, comparamos por separado el mejor software de gestión de riesgos.
Las señales de que esa escala ha llegado son concretas. Aparecen un segundo y un tercer proyecto, y hay que comparar los riesgos entre ellos. Alguien de fuera del proyecto pregunta por las amenazas en un corte concreto. El procedimiento exige riesgos en el acta y en el informe. A partir de ese punto, una lista con campos propios cuesta más trabajo del que ahorra.
Cómo probarlo en tu propio registro en dos semanas
Las comparaciones de funcionalidades deciden poco, porque la página de cada proveedor responde que sí a todo. Una prueba con tus propios datos dice más. Toma el registro de un proyecto en marcha y trasládalo entero, junto con tu escala de valoración. Ese primer paso muestra si tu matriz encaja en la herramienta sin cambiar los hábitos del equipo.
Luego cuatro pruebas. Vincula tres riesgos a tareas del cronograma y comprueba que puedes verlos en el diagrama de Gantt. Mueve una de esas tareas dos semanas y observa si cambia el panorama de amenazas. Construye un informe de riesgos para una categoría, proveedores por ejemplo, que abarque varios proyectos. Abre la pestaña de riesgos de la cartera y comprueba si alguna amenaza se repite en varios sitios. Esa última prueba suele justificar el cambio por sí sola.
Preguntas frecuentes
¿Tiene Asana un registro de riesgos?
Asana ofrece una plantilla de registro de riesgos y una de matriz. Producen una lista con campos como probabilidad, impacto, responsable y plan de respuesta. No es un módulo aparte, solo un proyecto hecho de tareas. Así que no puedes vincular un riesgo a una tarea del cronograma, compararlo entre proyectos ni verlo a nivel de cartera.
¿Qué diferencia hay entre un registro de riesgos y una lista de tareas con campos propios?
La misma que entre un riesgo y trabajo por hacer. Un registro trata el riesgo como un objeto aparte con su propio ciclo de vida, valoración, responsable, plan de respuesta y vínculos con el cronograma y el presupuesto. Una lista de tareas te deja registrar esa información pero no usarla fuera de un proyecto.
¿Qué se consigue vinculando un riesgo a una tarea del cronograma?
Muestra dónde en el plan está la amenaza. En FlexiProject una tarea con un riesgo vinculado lleva un icono de aviso en el diagrama de Gantt, y el color de al lado dice si el riesgo está activo. Tras cada cambio del cronograma ves qué amenazas se han vuelto más apremiantes.
¿Podemos conservar nuestra propia matriz de riesgos?
Sí. Las dimensiones de la matriz se fijan durante la implantación, así que una empresa que trabaja con una escala de tres por tres no tiene que pasar a cinco por cinco. Es una de las condiciones más importantes para que un módulo de riesgos se use en lugar de evitarse.
¿Cómo empezamos si nuestro registro de riesgos está hoy en Excel?
Trasladando un proyecto en marcha, junto con su escala de valoración y sus categorías actuales. La hoja de cálculo suele contener toda la información necesaria. Lo que le falta son los vínculos: con las tareas, con otros proyectos y con los documentos que rellenas a mano de todos modos. Esos vínculos son la razón para cambiar, no el mero hecho de mantener un registro.
La gente busca una alternativa a Asana para la gestión de riesgos del proyecto no porque no haya dónde registrar una amenaza. La razón es otra: una amenaza registrada luego no hace nada. Un registro que es una lista termina en la documentación. La información existe, pero no se conecta con el cronograma, no se suma entre proyectos, no vuelve a la empresa en el siguiente proyecto y hay que reescribirla en cada documento por separado. Un registro que es un módulo hace esas cuatro cosas por sí solo. Le deja al responsable lo único que ningún sistema hará por él: decidir cómo responder. Si tu registro hoy se actualiza sobre todo antes del comité de dirección, la forma más barata de comprobarlo es trasladar un proyecto y vincular tres riesgos a tareas del cronograma.
