Incidencia, riesgo o solicitud de cambio: en qué se diferencian

En cualquier proyecto aparecen tres tipos de «cosas que hay que atender» que se confunden a menudo: lo que ya ha pasado, lo que podría pasar y lo que alguien pide. Tratarlas igual es un error caro: cada una se gestiona de forma distinta, con otro responsable, otros plazos y otras consecuencias. Esta guía da una regla sencilla para distinguirlas y un ejemplo de cada una.

Las tres definiciones

La regla de decisión

Hazte tres preguntas, en este orden:

1. ¿Alguien está pidiendo algo que no estaba acordado? Si sí, es una solicitud de cambio, aunque la petición venga disfrazada de problema («el informe no tiene la columna de zona» puede ser un error, si estaba en el alcance, o un cambio, si no lo estaba).
2. Si no, ¿ha ocurrido ya? Si sí, es una incidencia.
3. Si no, ¿podría ocurrir? Entonces es un riesgo.

La primera pregunta es la más importante, porque es la que protege el alcance: un cambio tratado como incidencia se resuelve «gratis» dentro del presupuesto.

Un ejemplo de cada una

• Incidencia: «La carga de clientes ha fallado: faltan 300 registros». Ya ha pasado. Se asigna a alguien, se le da una gravedad y una prioridad, se imputan horas hasta resolverla y se cierra.
• Riesgo: «Si el cliente no entrega los datos de artículos antes del día 15, la migración se retrasará». Aún no ha pasado. Se anota con probabilidad e impacto y un plan: pedir los datos con antelación, preparar una carga parcial.
• Solicitud de cambio: «Queremos añadir un informe de ventas por zona». No estaba acordado. Se registra con quién lo pide, se estima el esfuerzo y se decide si se aprueba, y a qué coste.

Cómo se transforman entre sí

Las tres categorías no son compartimentos estancos:

• Un riesgo que ocurre se convierte en incidencia. Si el cliente no entregó los datos, ya no se vigila: se resuelve.
• Una incidencia puede revelar un cambio. Si al investigar un «fallo» resulta que el sistema hace lo acordado pero el cliente esperaba otra cosa, lo que queda es una solicitud de cambio.
• Una incidencia repetida suele esconder un riesgo que no se había visto: conviene anotarlo para que no vuelva a ocurrir.
• Un cambio aprobado puede traer riesgos nuevos: más alcance, menos margen.

Errores habituales

1. Mezclarlo todo en una lista única de «pendientes». Se pierde la distinción entre urgente, importante y opcional.
2. Tratar los cambios como incidencias para evitar la conversación incómoda con el cliente. El alcance se come el presupuesto sin que nadie lo vea.
3. No registrar riesgos hasta que se convierten en incidencias, cuando ya no hay margen para prevenirlos.
4. Poner a todas las incidencias la misma gravedad. La gravedad (cuánto daña) y la prioridad (cuándo se atiende) son ejes distintos: una incidencia puede ser grave y no urgente, o leve y urgente.
5. Cerrar sin registrar la causa, de modo que el aprendizaje se pierde.

Cómo se hace en PjMan

PjMan tiene un registro propio para cada una, dentro de cada proyecto, para que no se mezclen:

• Incidencias: entidad independiente de las tareas, con estado (de un catálogo de la organización que el PM configura; de fábrica Abierta, En análisis, En resolución, Resuelta y Cerrada), severidad y prioridad como ejes separados, asignados, horas estimadas e imputadas, fecha de detección y de cierre (que se pone sola al pasar a un estado final), y vínculo opcional a una fase o tarea. Tienen lista y tablero Kanban, y cuentan en los informes (abiertas, cerradas, tiempo medio de resolución, sin asignar). (Incidencias)
• Riesgos: con probabilidad, impacto, prioridad, estado y plan de mitigación. (Riesgos)
• Solicitudes de cambio: con solicitante, esfuerzo, coste y plazo estimados, y un estado pendiente, aprobado o rechazado. (Solicitudes de cambio)

Cada una tiene su código corto (I0003, R0002, S0001), que sirve para citarla en una conversación o pedírsela al asistente. La visibilidad también es distinta: la dirección del proyecto ve las tres, pero un consultor puede ver y crear incidencias ligadas a su trabajo y no accede a riesgos ni a solicitudes de cambio. (Roles y accesos) Informes reúne los indicadores de incidencias de tus proyectos. (Informes)

Para profundizar, las guías de registro de riesgos y de solicitudes de cambio tratan cada caso con más detalle.

Crea tu cuenta o explora la demo.

Preguntas frecuentes

¿Un error del cliente en sus datos es una incidencia o un cambio? Si bloquea el trabajo previsto, es una incidencia (hay que resolver el bloqueo). Si el arreglo implica trabajo que no estaba en el alcance, además hay un cambio que decidir.

¿Dónde anoto algo que podría pasar pero no sé cómo de probable es? En riesgos, con probabilidad media. Lo importante es dejarlo escrito y revisarlo.

¿Puedo convertir uno en otro? En PjMan cada registro es independiente; si un riesgo se materializa, registras la incidencia y cierras el riesgo. El histórico queda en cada registro.