Respuesta.

Los límites del proyecto (scope) son una definición clara de lo que debe ser realizado dentro del proyecto y lo que queda excluido de él. Una correcta definición de los límites proporciona comprensión del volumen de trabajo, previene el "scope creep" y permite controlar de manera efectiva los recursos y plazos.

El analista de negocios describe el scope mediante:

Mapa de partes interesadas.
Diagramas de contexto, límites e interfaces.
Catálogo de funciones en formato de user stories o use cases.
Manifiesto "out of scope" (exclusiones).

Características clave:

Los límites del proyecto se fijan antes de definir detalladamente los requisitos.
Sirven como referencia para acordar cualquier cambio.
Establecen un volumen medible de compromisos reales para el equipo.

Preguntas capciosas.

¿Es suficiente definir solo la lista básica de funcionalidades para considerar el scope como fijado?

No. Es necesario especificar explícitamente lo que NO está incluido en el proyecto para evitar interpretaciones dobles y "expectativas ocultas".

¿Tiene el analista de negocios derecho a ampliar el scope por su cuenta si lo considera útil?

No. Cualquier cambio en el scope debe ser aprobado por los clientes/partes interesadas y, como regla general, se formaliza a través del proceso de cambio (change request).

¿Se pueden cambiar los límites del proyecto después de su aprobación?

Sí, pero solo a través de un proceso formal de gestión de cambios, revisando los planes, costos, plazos y con el consentimiento de todas las partes interesadas clave.

Errores comunes y anti-patrones

Ausencia de una clara delimitación entre lo que está incluido/no incluido en el proyecto.
Adición de nuevas tareas sin considerar el impacto en los plazos y presupuestos.
Aprobación del scope solo verbalmente, sin documentación.

Ejemplo de la vida real

Caso negativo

El scope se define verbalmente, sin un documento claro. En el proceso, surgen tareas adicionales que los partes interesadas "esperaban".

Ventajas:

Flexibilidad, posibilidad de adaptarse a nuevas tareas.

Desventajas:

El proyecto se sale de los plazos y el presupuesto, surgiendo malentendidos entre el equipo y el cliente.

Caso positivo

El analista documenta el scope, acuerda exclusiones, y cualquier cambio pasa a través del sistema de change requests.