Plan de Gestión del Alcance

Sistema de Control y Soporte a la toma de decisiones de la Gestión

Nombre del Proyecto:
Comercial
Preparado por: Juan Carlos Dávila T.
Fecha: 30/05/2008
1. Describir cómo será administrado el alcance del Proyecto:

Después que el Project Charter y todas sus referencias han sido creadas o modificadas, el project
manager preparará, actualizará y validará el documento final del alcance y finalmente lo mostrará al
equipo del proyecto para su validación. Un representante del usuario debería siempre aprobar el alcance.
Cualquier corrección o modificación pueden ser aplicadas al finalizar esta revisión. El project sponsor
puede firmar una aprobación adicional.

El alcance aprobado y sus componentes de referencia son congelados. Se realiza el baseline conforme el
procedimiento de generación de línea base (baseline) del cronograma. Cualquier cambio debe pasar por
un proceso de control de cambios. El Alcance y sus componentes son disponibles para las personas
asociadas al proyecto con acceso de SOLO LECTURA.

2. Evaluar la estabilidad del alcance del proyecto (cómo manejar los cambios, la
frecuencia e impacto de los mismos):

Se requiere de un proceso formal de Control de Cambios en los casos que el cambio afecte la línea base
del proyecto debido a:
 Retrasos en desarrollo o revisiones del requerimiento.
 Afinación de estimaciones
 Cambios en la dirección u objetivos del proyecto.
 Requerimientos nuevos
 Cambio de metodología
 Una vez aprobados, se procederá al procedimiento de regeneración de línea base de ser necesario.

Se debe especificar en el Plan de Proyecto el equipo de control de cambios. El equipo puede estar
conformado por el project sponsor, project manager, y otras personas relacionadas con el proyecto. El
responsable del equipo es representado por el project sponsor u otra persona que éste asigne.
 Inicio

360 OR

Crear la solicitud
de cambio

365 PM

Revisar cambio y
hacer
recomendaciones

370 ECC

Revisar solicitud
de cambio
PARTICIPANTES

OR: Originador del cambio

375 ECC
PM: Project Manager
Tomar la
ECC: Equipo de Control decisión sobre la
de Cambios solicitud de
RCC: Responsable de cambio
equipo de Control de
Cambios
380 ECC 385 ECC
AR: Analista responsable

¿Diferido o Notificar al PM y
SI
pendiente? al Originador

NO

390 ECC

¿Aprobado?

SI

395 AR, PM
Actualizar los
cambios / NO
Rebaseline

400 PM

Cambiar el
estado a la
solicitud

405 PM
Notificar el
cierre de la
solicitud

Fin
DESCRIPCIÓN DEL PROCEDIMIENTO

1.1. ACTIVIDAD 360: CREAR LA SOLICITUD DE CAMBIO

El originador del cambio (persona del equipo que identifica el cambio) lo documentará e ingresará la
información requerida en el sistema. En caso no se utilice un sistema automático, debe ingresar la
información en el formulario de solicitud de control de cambios. Entre la información requerida se
encuentra:
 Nombre del originador
 Nombre del requerimiento de cambio
 Fecha de identificación
 Persona que requiere el cambio: equipo de proyectos, proveedor o usuario
 Prioridad
 Fase de administración del proyecto
 Fase del producto
 Requerimientos que impacta el cambio
 Tipo de cambio
 Descripción del cambio
 Razón del cambio
 Equipo de proyecto impactado
 Administrador/Líder del proyecto
Se debe incluir el nombre de todos los documentos que serán modificados en caso de que el cambio sea
aprobado (por ejemplo: plan de proyecto, documento de análisis y diseño técnico, etc). Esta información
se debe ingresar en el campo Descripción del cambio. Si el cambio es aprobado, los documentos deben
ser actualizados para que reflejen estos cambios. Se debe actualizar la sección de Revisiones indicando
el cambio realizado asociado con la aprobación del mismo. Los documentos deben ser revisados para
asegurarse que los cambios se han implementado correctamente sin necesidad que se realice otra
aprobación formal.
El project manager debe guardar un listado con todos los cambios que han sido presentados el cual se
actualizará conforme el equipo de control de cambios realice la evaluación respectiva.

1.2. ACTIVIDAD 365: REVISAR EL CAMBIO Y HACER LAS RECOMENDACIONES AL

EQUIPO DE CONTROL DE CAMBIOS (APROBAR O RECHAZAR)
El requerimiento de cambio es enviado al project manager para su revisión y recomendaciones al equipo
de control de cambios.
 El project manager evalúa el cambio, teniendo en cuenta el impacto en el negocio, para el usuario,
técnicos o de cronograma.
 Determina los cambios y estima el esfuerzo que requiere su implementación.
 Identifica cualquier cambio en el proyecto si el cambio es aprobado.
Si la solicitud es válida, se complementa el análisis y se recomienda una aprobación, caso contrario, se
recomienda una desaprobación.
Las recomendaciones (aprobado o rechazado) deben ser enviadas al responsable del equipo de control
de cambios. Esta recomendación debe indicarse en la solicitud de cambio.

1.3. ACTIVIDAD 370: REVISIÓN DE LA SOLICITUD DE CAMBIO

El equipo de control de cambios debe revisar todas las solicitudes de cambios. La actividad principal del
responsable del equipo de control de cambios es de revisar todas las solicitudes de cambios, supervisar
las reuniones, monitorear y hacer seguimiento a las solicitudes de cambio.
En algunos casos, el equipo de control de cambios asignará al project analyst, quien cumplirá el rol de
coordinador, teniendo la tarea de crear la agenda de la reunión y almacenar toda la documentación de
cada solicitud de cambio.
El responsable del equipo de control de cambios podrá invitar a otras personas necesarias a la reunión
de revisión del equipo de control de cambios para que apoyen en la toma de decisiones.

1.4. ACTIVIDAD 375: TOMAR LA DECISIÓN SOBRE LA SOLICITUD DE CAMBIO

Basado en el análisis anterior, el equipo de control de cambios puede tomar una de estas decisiones:
 Diferir solicitud de cambio: El equipo puede decidir diferir la solicitud de cambio para
una nueva fecha o hasta que alguna información adicional sea necesaria entregar a este equipo.
 Rechazar solicitud de cambio: Si el equipo rechaza la solicitud de cambio, el equipo
debe comunicar la decisión y sus razones la originador del cambio.
 Aprobar o Aprobar con modificaciones: Si el requerimiento es aprobado, esta
decisión es comunicada automáticamente al originador del requerimiento. Asimismo, el equipo puede
realizar modificaciones a la solicitud de cambio antes de la aprobación. El project manager indicará
los recursos apropiados para la implementación.
 Realizar el análisis de impacto detallado: Si el equipo de control de cambios
encuentra que es necesario realizar un análisis adicional, puede requerir que se complete la
información de análisis de impacto detallado o a nivel general. Esta información es la siguiente:
 Impacto en el presupuesto.
 Impacto en el cronograma.
 Impacto en recursos.
 Impacto en otros equipos o aplicaciones.
 Impacto en el tamaño del proyecto.
 Impacto en arquitectura.
 Supuestos, riesgos y dependencias.
Se debe incluir la documentación adicional necesaria para este análisis.
El responsable del equipo de control de cambios debe indicar el resultado de la evaluación en la solicitud
de cambio.

1.5. ACTIVIDAD 380: ¿LA SOLICITUD ES DIFERIDA O ESTÁ PENDIENTE?

En caso la solicitud se encuentre diferida o pendiente, continuar con la actividad 385. Caso contrario con
la actividad 390.

1.6. ACTIVIDAD 390: ¿LA SOLICITUD ES APROBADA?

Si la solicitud es aprobada, continuar con la actividad 395, caso contrario con la actividad 400.

1.7. ACTIVIDAD 385: NOTIFICAR AL PM Y AL ORIGINADOR

La solicitud diferida, con las razones respectivas, son retornadas al projct manager e incluye las
instrucciones para que sea reactivada. El responsable del equipo comunica esta decisión al originador de
la solicitud de cambio.

3. ¿Cómo los cambios al alcance, serán identificados y clasificados?

Los cambios de alcance serán identificados de acuerdo al procedimiento de la respuesta anterior.

Los niveles de aprobación de los cambios de alcance se darán en función de la categorización del
proyecto (basada en el tamaño del proyecto)

Tamaño Número de horas Nivel de autorización

Pequeño 1 a 25 Hrs Project Manager
Mediano 26 a 100 Hrs Project Manager
Grande 101 a 500 Hrs Sponsor
 Muy Grande 501 a mas Hrs Gerente General

4. Describir cómo los cambios del alcance serán integrados al proyecto:

ACTIVIDAD 395: ACTUALIZAR LOS CAMBIOS / REBASELINE

El equipo de implementación (a cargo de un analista responsable) completará las actividades que han
sido asignadas por el equipo de control de cambios. El equipo de implementación realizará la
implementación respectiva y entregará la documentación completa necesaria al equipo de control de
cambios. Si los cambios a realizarse impactan en el cronograma por más de 1 semana, se deberá
realizar un rebaseline a éste.

ACTIVIDAD 400: CAMBIAR EL ESTADO A LA SOLICITUD

Una vez entregada esta información, el equipo de control de cambios cambiará el estado a la solicitud y
adicionará la documentación relacionada. (DIFERIDA, COMPLETADA, RECHAZADA)

ACTIVIDAD 405: NOTIFICAR EL CIERRE DE LA SOLICITUD

El responsable del equipo realizará lo siguiente:
 Notificará al equipo.
 Notificará al originador del cambio.

5. Comentarios adicionales:

Anexo 1: Formulario de solicitud de control de cambios

Formulario de solicitud de cambio

Número de solicitud de cambio: (Será asignado Fecha de solicitud:
por el Project Manager)
Nombre de solicitud de cambio: (máximo 10 palabras)
Originador: Dirección electrónica del Originador:
Nombre del proyecto: Project Manager:
Prioridad del cambio: Responsable del Equipo de Control de Cambios:
(Seleccionar Baja / Media / Alta)
Fase del proyecto: (Inicio, Planificación, Ejecución, Fase del producto: (Ingrese la fase de desarrollo del
Control, Cierre) producto; análisis funcional, análisis técnico,
construcción, pruebas, implementación, capacitación)
Tipo de cambio: (hardware, software,
documentación, requerimiento, alcance, cronograma,
capacitación, etc)
Descripción del cambio:
Adicione una breve descripción del cambio solicitado. Esta debe incluir cualquier cambio en recursos,
entregables, tiempos y presupuesto.
Razón del cambio:
Liste las razones del cambio (circunstancias externas, error / omisión en el alcance o funcionalidad requerida,
adición de valor, etc)
Motivos de negocio: Motivos del sistema:
Liste los motivos del negocio por lo cual es Liste los motivos del sistema por lo cual es necesario
necesario este cambio (por ejemplo: recientes este cambio (por ejemplo: mejora en el rendimiento
cambios en políticas internas, etc) del sistema, falta de apoyo del proveedor, etc)

Impacto en el negocio: Impacto en el proyecto:

Describe el impacto en el negocio si es que el cambio Describe el impacto en el alcance y/o cronograma si
es implementado (por ejemplo: recursos adicionales. el cambio es implementado (por ejemplo:tiempo de
disminución de la eficiencia del proceso, cambios en integración, requerimiento de nuevos procesos,
la estructura organizativa, etc) modificación de fecha comprometida, etc)
 Beneficios del cambio: Impacto en costos:
Describe los beneficios financieros y no financieros Describe los costos financieros o no financieros
relacionados con la implementación de este cambio asociados con la implementación de este cambio (por
(por ejemplo; reducción en los costos por transacción, ejemplo: ampliación de presupuesto, reducción
mejorar performance, aumentar la satisfacción del temporal del rendiemiento delpersonal, etc)
cliente, etc)
Equipos de proyecto impactados:
 Liste todos los equipos de proyecto impactados por este cambio, incluyendo al líder del equipo.
Documentación de soporte:
Incluir cualquier documentación que pueda sustentar el cambio solicitado.

Resultado de la evaluación del Project Manager Resultado de la evaluación del Equipo de Control de
Cambios
___ Aprobado ___ Diferido
___ Rechazado ___ Rechazado
___ Aprobado
___ Aprobado con modificaciones
___ Realizar análisis de impacto detallado

Anexo 2: Listado de solicitudes de cambio

Nro Aplicativ Cambio Fecha de Originador Asignado Fecha de Estado Solución

o solicitud a rpta