Plan de Proyecto

Cliente: <NOMBRE DEL CLIENTE>

Proyecto: <NOMBRE DEL PROYECTO>
Versión: <>
 Plan del Proyecto

1 Sumário
2 INTRODUCCIÓN 3
3 RESUMEN DEL PROYECTO 4
3.1 Nombre del Proyecto 4
3.2 Patrocinador (Sponsor): 5
3.3 Product Owner, autoridad y responsabilidad atribuida: 5
3.4 Presentación del Proyecto: 5
3.5 Expectativa del cliente y de las partes interesadas (Stakeholders): 5
3.6 Factores de éxito del proyecto: 5
3.7 Macro Alcance: 5
3.8 Restricciones: 5
3.9 Premisas:7
3.10 Límites del proyecto (exclusiones): 8
3.11 Control y gestión de las informaciones del proyecto: 8
3.12 Registro de las alteraciones del Plan de Proyecto:8
3.12.1 Registro de las alteraciones 8
4 GESTIÓN DE ALCANCE 8
4.1 Declaración de Alcance 8
4.1.1 Descripción de alcance de los productos 8
4.1.2 Límites de Proyecto (exclusiones de alcance) 8
4.1.3 Plan de entregas y marcos del proyecto 9
4.2 EAP con su diccionário 9
4.3 Reglas para solicitar cambios de alcance: 10
5 GESTIÓN DE TIEMPO 13
5.1 Macro de Entregables – Baseline PMS – (Vinculados a EAP con Milestones) 13
5.2 Cuadro de actividades detallados con base en la lista de actividades 13
Reglas para solicitación de cambios, acciones correctivas o preventivas a partir del análisis del cuadro de actividades: 13
6 GESTIÓN DE PRESUPUESTO (HORAS) 14
6.1 Proceso para estimar horas para las actividades del ciclo 14
6.2 Presupuesto detallado para este proyecto: 15
6.1 Cambios en la línea de base de costos (presupuesto aprobado): 15
6.1 Proceso para medición de desempeño de los costos (reuniones): 15
6.1 Previsiones y estimativas (a partir de los reportes de desempeño): 15
6.1 Gerenciar variaciones en la línea de base de costos (horas):15
6.2 Reserva para contingencia: 15
6.3 Reserva gerencial (otras reservas): 15
6.4 Reglas para utilización de las reservas: 15
7 GESTIÓN DE CALIDAD 16
7.1 Métricas y metas de calidad: 16
7.2 Listas de verificación de la calidad: 16
8 Cambios, acciones correctivas y acciones preventivas en las normas de calidad establecidas y aprobadas:
17
8.1 Reglas para mediciones de control de calidad de las entregas: 17
Guía de Referencia Versión 10.0
PAG
 Plan de Proyecto

8.2 Reglas/Actividades relacionadas a la gestión de la Garantía de Calidad: 18

8.3 Proceso para registrar errores y problemas: 19
8.4 Reglas para cuestiones de calidad no previstas en este plan: 19
9 GESTIÓN DE PERSONAL 19
9.1 Matriz de atribución de responsabilidades: 19
9.2 Funciones, autoridad, responsabilidad y competencias necesarias para los miembros del proyecto: 19
9.3 Organigrama del Proyecto: 21
9.4 Histograma de recursos: 21
9.5 Necesidad de capacitación identificada: 21
9.6 Plan para evaluación de desempeño del equipo: 21
9.7 Registro de problemas relacionados al equipo: 21
10 GESTIÓN DE LAS COMUNICACIONES 21
10.1 Planificación de las Comunicaciones: 21
10.2 Reglas y criterios para distribución de las informaciones: 21
10.3 Formato y reglas para comunicar desempeño del proyecto:22
10.4 Proceso para administrar las comunicaciones con las partes interesadas: 24
10.5 Reglas para registro de problemas y reclamaciones de las partes interesadas: 25
11 GESTIÓN DE RIESGOS 25
11.1 Proceso para identificar los riesgos: 27
11.2 Proceso para calificar y priorizar los riesgos identificados: 27
11.3 Proceso para calificar el impacto de los riesgos en los objetivos del proyecto: 28
11.4 Reservas para los riesgos identificados: 29
11.5 Reservas para riesgos no identificados: 29
11.6 Reglas para utilización de las reservas: 29
11.7 Proceso para planificar respuestas a los riesgos identificados: 29
11.8 Proceso para controlar los eventos de riesgos: 30
11.9 Proceso para registro de los riesgos: 30
11.10 Reglas para solicitar cambios en el proyecto en función de la identificación de nuevos riesgos: 31
11.11 Reglas para actualizar este plan a partir de cambios en los riesgos: 32
11.12 Reglas para cuestiones de riesgos no previstas en este plan: 32

2 INTRODUCCIÓN
El propósito de ese documento es establecer el entendimiento común entre los patrocinadores y el equipo de proyecto, en relación a
las expectativas y objetivos del proyecto. El Plan de Proyecto establece los fundamentos y estrategias del mismo, documentando:

● Objetivos;

● Alcance de Servicios;

● Alcance Funcional;

● Alcance Técnico;

● Alcance de Actividades;

● Alcance Geográfico y Organizacional;

Guía de Referencia Versión 10.0

PAG
 Plan del Proyecto

● Costos;

● Riesgos;

● Personas involucradas (Stakeholders);

● Premisas;

● Factores de éxito;

● Planificación.

El plan de proyecto es la declaración de entendimiento de los objetivos del proyecto y comprometimiento de todos los participantes.
Siendo así, su entendimiento es extremamente importante. También es la base para evaluar cualquier alteración de alcance y
objetivos del proyecto, además del análisis del impacto de las alteraciones propuestas en los plazos y costos. El plan de proyecto es la
base para el proceso de ejecución del equipo de proyecto, y también servirá como base para evaluar el desempeño, dirección y
resultados del proyecto por los “stakeholders” del mismo.

Estrategia
La estrategia adoptada para la implantación y gestión de proyectos involucra:

● El entendimiento y alineación de expectativas entre “GRUPO” <Nombre del canal> y <Nombre del Cliente> en relación a los
plazos y alcance del proyecto y, todavía, una clara definición sobre los productos finales a ser entregados y sus responsabilidades;

● La aplicación de la metodología de gestión de proyectos acordada en este documento tiene como base la MIT (Metodología de
Implantación “GRUPO”);

● Nombrar el Gestor de Proyecto, el cual tendrá la función de planificar, controlar, medir y acompañar toda la evolución del
proyecto, hasta la entrega oficial del mismo. El Gestor controlará la calidad y productividad del equipo participante, realizando los
ajustes que sean necesarios.

● Serán asignados consultores especialistas en los módulos y servicios comprados, garantizando el entendimiento de las áreas
usuarias, así como la correcta configuración y entrega del producto.

Este texto debe ser eliminado <CASO EXISTAN ÍTEMS ESPECÍFICOS EN RELACIÓN A LAS ESTRATEGIAS ADOPTADAS CON EL
CLIENTE, POR FAVOR, MENCIONAR AQUI>

● Control de los servicios desarrollados para garantizar la total adherencia a las expectativas de <Nombre del Cliente>, de acuerdo a
lo descrito explícitamente en el alcance del proyecto de este documento.

No se aceptarán alteraciones en el alcance sin antes pasar por un proceso de cambio formal.

Se entiende por alteración de alcance cualquier ítem que no se encuentre explícitamente descrito y aquellos explícitamente descritos
en el ítem “Ítems fuera de alcance” de este documento. Alteraciones en este documento serán realizadas de forma controlada y
comunicadas con el resultado de las decisiones en consenso, lo cual solo será posible antes de la aceptación por parte de los
participantes y sus correspondientes firmas en el documento.

Esos cambios serán comunicados, formalmente, a los miembros del proyecto, para asegurar que los mismos serán informados por el
alto escalón del proyecto.

El Comité Directivo, exclusivamente, tiene la responsabilidad y autoridad necesarias para promover y decidir los cambios solicitados.

Guía de Referencia Versión 10.0

PAG
 Plan de Proyecto

3 RESUMEN DEL PROYECTO

3.1 Nombre del Proyecto

<Nombre del Proyecto>

3.2 Patrocinador (Sponsor):

<Nombre del Patrocinador>

3.3 Product Owner, autoridad y responsabilidad atribuida:

<Nombre del PO. Citar referencia de la Matriz de Responsabilidad>

3.4 Presentación del Proyecto:

Describa las principales situaciones y deficiencias de la gestión actual del negocio para comprobar los resultados futuros.

Este texto debe ser eliminado <DESCRIBIR AQUI LOS OBJETIVOS Y JUSTIFICATIVAS DEL PROYECTO EN LA PERSPECTIVA DEL
CLIENTE. EL QUE CONTRIBUYE E IDENTIFICÓ LA NECESIDAD DEL CLIENTE. ESTE TIPO DE INFORMACIÓN PUEDE SER
RECOGIDA DE LA ÁREA COMERCIAL Y DE PREVENTA>

3.5 Expectativa del cliente y de las partes interesadas (Stakeholders):

<Relacionar la principal expectativa de los interesados más importantes>

3.6 Factores de éxito del proyecto:

<Enumerar los principales factores, que contribuyen para el éxito del Proyecto, previamente identificados>

3.7 Macro Alcance:

<Foto de WBS en relación al nivel de entregables>

3.8 Restricciones:
<Restricciones previamente identificadas y negociadas para el proyecto como: Plazos/Costo/Clausulas
Contractuales/Multas/Bonos etc.>

<REVISAR TODO ESTE ÍTEM. OBSERVE PARA NO HABER CONTRADICCIÓN CON EL ALCANCE DEL PROYECTO >

No forman parte del alcance de esta propuesta los ítems descritos a continuación:

● Especificación de sistemas y/o funcionalidades que no participan de la implantación de los productos “GRUPO”;

● Desarrollo de programas o productos específicos complementarios al producto estándar, excepto los que ya fueron previstos en
el ítem “Especificación de Personalización”;

● Desarrollo de programas específicos de interface entre los productos “GRUPO” con otros softwares, existentes o a ser adquiridos,
en las instalaciones de <Nombre del Cliente >;

Guía de Referencia Versión 10.0

PAG
 Plan del Proyecto

● Desarrollo de programas específicos para la importación de la carga de datos, excepto los previstos “en contrato”. Recordamos
que “GRUPO” dispone un conjunto de programas estándar para la importación de esta carga y que, en el caso de que <Nombre
del Cliente> necesite, por razones específicas, nuevos programas, serán realizados los respectivos presupuestos;

● Ejecución y desarrollo de programas para extracción de datos de las bases de datos de los sistemas legados de <Nombre del
Cliente >;

● Inserción de datos en las bases de los productos “GRUPO”, manual o electrónicamente. “GRUPO” orientará y transferirá, durante
la implantación, conocimientos al equipo de proyecto de <Nombre del Cliente> para que el mismo alimente las bases de datos,
proveyendo los layouts y programas para las referidas importaciones;

● Capacitación para usuarios finales y de implantación de cualquier módulo y proceso que no participe explícitamente del capítulo
“Alcance Funcional”;

● Instalación de productos en otras unidades y locales de <Nombre del Cliente> que no se encuentren declaradamente citadas en
contrato;

● Suministro de softwares o hardwares básicos para el desarrollo del proyecto (herramientas de programación, sistema
operacional, editor de texto, planillas electrónicas y reportes exigidos por <Nombre del Cliente> no previstos en el sistema);

● Suministro de softwares de seguridad para sistemas operacionales;

● Configuración de red o instalación de softwares básicos;

● Configuración de links de acceso remoto entre puntos distintos;

● Servicios de administración de banco de datos;

● Rutinas de backup de servidores o bancos de datos;

● Reuniones extraordinarias, excepto las de puntos de control, previstas en el proyecto;

● Horas utilizadas para la presentación del trabajo efectuado o a ser realizado para los diversos niveles de la empresa por
solicitación de la misma;

● Repetición de trabajos causada por falta de definición o capacidad del usuario designado por <Nombre del Cliente> para la
realización de la actividad, o por la sustitución del mismo;

● Repetición de trabajos causada por problemas en el ambiente operacional y en función de cambios administrativos que resultan
en alteraciones de los procesos previstos al inicio de la implantación;

● Repetición de trabajos causada por problemas en las actividades de responsabilidad de los usuarios que resultan en la ejecución
de actividades adicionales no previstas en el ciclo (sprint);

Guía de Referencia Versión 10.0

PAG
 Plan de Proyecto

● Horas en las cuales el consultor “GRUPO” <Nombre del Canal> acompañó la ejecución de una actividad prevista en el cuadro de
actividades, que debería haber sido ejecutada previamente a la visita del consultor, por un profesional de <Nombre del Cliente >;

● Horas de consultor “GRUPO” <Nombre del Canal> utilizadas para la ejecución de actividades que son de responsabilidad de
<Nombre del Cliente>, como apertura y acompañamiento de Llamados, configuración de hardware y software, actualización de
programas, construcción de reportes, construcción de programas específicos, apoyo a la infraestructura.

● Cualquier ítem que no se encuentre explícitamente descrito en este documento.

Serán consideradas como horas improductivas para el correcto desarrollo de los dos trabajos, buscando preservar la relación
costo/beneficio:

● Todo y cualquier obstáculo para la ejecución de los trabajos ocasionados por atrasos de actividades de responsabilidad de
<Nombre del Cliente> en el cuadro de actividades;

● Falta de recursos de responsabilidad de <Nombre del Cliente> para ejecutar las actividades previstas en el cuadro de actividades;

● Horas de locomoción para la realización de trabajos en otras unidades de <Nombre del Cliente>, en las cuales estos trabajos no
hayan sido previamente planificados;

● Horas en las cuales el Consultor de “GRUPO” estuvo esperando, por cualquier motivo, la asignación de un profesional de <Nombre
del Cliente> o recursos técnicos de hardware o software para la ejecución de actividades previamente programadas en los ciclos
(sprints).

● En el caso de que ocurra cualquier ítem de los anteriormente mencionados, el Gestor de Proyectos del Cliente será comunicado y
las horas correspondientes serán apropiadas en las Fichas de Apropiación y facturadas como fuera de alcance.

3.9 Premisas:
< Premisas confirmadas como verdaderas para el proyecto (Disponibilidad de recursos/Importaciones de datos)>

Son artefactos / influencias externas que pueden afectar directamente la evolución o éxito del proyecto, para el cual el Gestor de
Proyecto no posee control directo.

Identificamos las siguientes premisas para garantizar el éxito del Proyecto:

● La metodología de implantación a ser utilizada será la Metodología de Implantación “GRUPO” (MIT), modalidade Série 3. Toda la
documentación será realizada de acuerdo con las normas utilizadas por la contratada. En el caso de que sea necesaria la
utilización de una metodología específica, un presupuesto de horas podrá ser presentado al Cliente.

● Agilidad en la aprobación de la documentación del Proyecto, como, Plan de Proyecto, Actas de Reunión y Evaluaciones
Complementarias, considerando los plazos acordados, para no afectar la evolución de las demás actividades. Una fase de la
metodología solo será iniciada después de la aprobación formal de la fase que la precede.

● El cliente debe tener capacidad de recuperación de datos, como Backup, proceso paralelo, seguridad de datos, plan de
contingencia, etc.

Guía de Referencia Versión 10.0

PAG
 Plan del Proyecto

● Backups y mantenimiento de red de __________ (empresa Cliente), que afecten la evolución programada del Proyecto, deben ser
previamente acordados con “GRUPO”.

● Disponibilización de infraestructura básica necesaria para la realización del Proyecto:

o Línea telefonica con acceso a llamadas (a todo el país) para el equipo
o PC compatible con los siguientes aplicativos instalados, por consultor:
▪ Office

▪ Producto “GRUPO”

▪ Conección a la red corporativa por consultor

▪ Impresora compatible

▪ Acceso Internet , inclusive para “download” de archivos

▪ Cuenta correo electrónico (opcional)

▪ Accesos a las siguientes direcciones:

o Identificación

● Disponibilidad y asignación de recursos identificados y listados en el Plan de Proyecto. Comprometimiento y entendimento de los
objetivos y metas del Proyecto por todos los participantes (stakeholders). Entendimento completo del flujo operacional y de
negocio de las áreas participantes, por parte del Equipo de Implantación del Cliente, los cuales fueron identificados por <nombre
del Cliente> y listados en este documento.

<RETIRAR ESTE TEXTO – Identifique particularidades del Proyecto e incluya aqui>

3.10 Límites del proyecto (exclusiones):

<Funcionalidades que no están incluídas / Reportes / Migraciones>

3.11 Control y gestión de las informaciones del proyecto:

<Breve descripción de la forma de almacenamiento de la documentación del Proyecto y controlada por intermedio de versiones >

3.12 Registro de las alteraciones del Plan de Proyecto:

3.12.1 Registro de las alteraciones

Fecha Alteración Motivo Aprobado por

4 GESTIÓN DE ALCANCE

4.1 Declaración de Alcance

< Incluir o excluir funcionalidad (módulo) de acuerdo con la Propuesta Comercial. Apenas las funcionalidades que realmente serán
implantadas de acordo con la evaluación oficial del proceso >

Guía de Referencia Versión 10.0

PAG
 Plan de Proyecto

4.1.1 Descripción de alcance de los productos

Proceso / Vertical Módulo Definido por Aprobado por

Entradas Compras Líder de Proceso 1 Product Owner

4.1.2 Límites de Proyecto (exclusiones de alcance)

Proceso / Vertical Módulo Definido por Aprobado por

Entradas Compras Líder de Proceso 1 Product Owner

4.1.3 Plan de entregas y marcos del proyecto

Entrega Descripción Término

Fase de Iniciación Cláusula de Apertura
Product Owner Definido
Presentación de la Gestión de Projetos
Reunión de Apertura de Proyecto
Fase de Planificación Modelado de los procesos validados
Plan de proyecto Validado
Fase de Ejecución Producto instalado
Producto parametrizado
Equipo de implantación del cliente capacitado
Prototipos realizados y validados
Actividades iniciales acompañadas
Primeros cierres acompañados
Fase de Cierre Proyecto realizado
Lecciones Aprendidas realizadas
Proyecto Transitado para AR

4.2 EAP con su diccionário

Guía de Referencia Versión 10.0

PAG
 Plan del Proyecto

ID de EAP Paquete de Trabajo Descripción Critérios de Aceptación

4.3 Reglas para solicitar cambios de alcance:

< Citar las reglas de cambio de alcance y sus impactos, presentar formulario MIT031 – Solicitación de Cambios y confirmar el
entendimiento de los organigramas presentados >

Guía de Referencia Versión 10.0

PAG
 Plan de Proyecto

Compentecias y prioridades:
● Cambios con prioridad 0 (cero) – Urgente, con alto impacto en el proyecto y en otras áreas sobre las cuales el Product Owner no
tiene autonomía. Requieren una acción inmediata por parte del Product Owner, el cual debe accionar, inmediatamente, el
patrocinador.

● Cambios con prioridad 1 (uno) – Urgente. Requiere una acción inmediata por parte del Product Owner, independiente de las
reuniones de control previstas, accionando inmediatamente el patrocinador en el caso de necesidad de autorizaciones financieras
fuera de la competencia del Product Owner.

Guía de Referencia Versión 10.0

PAG
 Plan del Proyecto

● Cambios con prioridad 2 (dos) – Urgente, pero sin impacto significativo en los costos y plazos del proyecto. Requiere una
planificación de la acción por intermedio de terceros o de equipos que, en principio, tengan disponibilidad, una vez que agregan
valor al éxito del proyecto.

● Cambios con prioridad 3 (tres) – No impactantes o urgentes. Cambios de prioridad tres pueden ser implementadas por tener
influencia en el éxito del proyecto.

Modelo de flujo para control de los cambios (alcance y calidad)

Guía de Referencia Versión 10.0

PAG
 Plan de Proyecto

5 GESTIÓN DE TIEMPO

5.1 Macro de Entregables – Baseline PMS – (Vinculados a EAP con Milestones)

<Citar documento TabLa de las principales fases con estimativas de las fechas. Debe evaluarse la existencia de proyectos de
personalizaciones relacionados al proyecto oficial que puedan causar impactos en el proyecto.>

Puntos de Control Fecha Estimada

Aprobación del Plan de Proyecto
Modelado de los Procesos
Instalación del Producto
Parametrización del sistema
Capacitación del equipo de implantación del
cliente
Prototipos
Homologación Actividades Iniciales
Homologación Primeros Cierres
Cierre del Proyecto

5.2 Cuadro de actividades detallados con base en la lista de actividades

<Citar documentos del cuadro de actividades previstas para el proyecto. Aplicar el MIT555 – Cuadro de Actividades.>

Reglas para solicitación de cambios, acciones correctivas o preventivas a partir del análisis del cuadro
de actividades:
Proceso, reglas y criterios para cambios en los plazos (competencias y prioridades), como en el ejemplo detallado a continuación:

● Atrasos con prioridad 0 (cero) – Urgente y de alto impacto en el proyecto y con soluciones inicialmente no
identificadas. Requieren una acción inmediata por parte del Product Owner y Scrum Máster, que deben accionar
inmediatamente el patrocinador para discusión y análisis.

● Atrasos con prioridad 1 (uno) – Urgente. Requiere una acción inmediata por parte del S crum Máster y Product Owner,
independientemente de las reuniones de control previstas, accionando las medidas de recuperación de plazos
disponibles, tales como Fast Tracking o Crashing, el trabajo en horas extra, banco de horas y esfuerzo en conjunto.
Los costos que resulten de esas acciones deben ser asignados en las reservas gerenciales

● Atrasos con prioridad 2 (dos)– Requieren una nueva planificación de las actividades futuras, pues el proyecto,
todavía, no completó el 25%

● Atrasos con prioridad 3 (tres) – Pequeños si se comparan con la duración del proyecto – Pueden ser modificados, sin
que sea necesario planificar nuevamente o accionar algún tipo de mecanismo de recuperación.

Modelo de flujo para control de los cambios en los plazos:

Guía de Referencia Versión 10.0

PAG
 Plan del Proyecto

6 GESTIÓN DE PRESUPUESTO (HORAS)

6.1 Proceso para estimar horas para las actividades del ciclo
Como fueron estimadas las cantidades de horas por tarea? <Presentar el proceso utilizado para estimar las horas de los entregables
del proyecto >.

Guía de Referencia Versión 10.0

PAG
 Plan de Proyecto

6.2 Presupuesto detallado para este proyecto:

< Completar el modelo a continuación o citar el documento del contrato oficial del proyecto >

Horas de Analista:
Horas de Coordinación / Gestión:
Horas de Traslado:
Valor de gastos:
Valores de gastos pueden ser convertidos en horas?

Presupuesto total del proyecto (horas)

1.1 Cambios en la línea de base de costos (presupuesto aprobado):

<Describir las actualizaciones de presupuesto aprobadas que provienen de actualizaciones de alcance/riesgos/cambios en los valores
hora del equipo/descuentos horas de inversiones/repetición de trabajos etc>

1.1 Proceso para medición de desempeño de los costos (reuniones):

<Definir un proceso para acompañar el desempeño financiero del proyecto >

1.1 Previsiones y estimativas (a partir de los reportes de desempeño):

<Definir un proceso para evaluar las previsiones de costo al término del proyecto con base en los reportes de PMS >

1.1 Gerenciar variaciones en la línea de base de costos (horas):

<Evaluar la necesidad de reglas para administrar las variaciones no previstas de costos en el proyecto con el objetivo de mantener sus
ganancias dentro de lo previsto.>

1.2 Reserva para contingencia:

< Evaluar contrato del Proyecto. Evaluar la existencia de reservas financieras negociadas y previstas en contrato >

1.3 Reserva gerencial (otras reservas):

<Evaluar contrato del Proyecto - Evaluar la existencia de reservas financieras negociadas y previstas en contrato >

1.4 Reglas para utilización de las reservas:

Reglas para la utilización de las reservas para cambios en el proyecto, como descritas en el ejemplo a continuación:

Todas las medidas de recuperación de atrasos en los proyectos, que requieran gastos adicionales, deben ser asignadas dentro de las
reservas gerenciales del proyecto, en la categoría Otras Reservas, desde que dentro de la competencia del Product Owner.

Para tomar medidas prioritarias, para la recuperación de plazos, que no se encuentren dentro de la competencia del Product Owner, o
cuando no existan más reservas gerenciales disponibles, debe ser accionado el patrocinador, o solicitado, al directorio de la empresa,
un aumento de las reservas gerenciales.

Ejemplo - Autonomía para utilización de las reservas por el Product Owner:

Las reservas serán utilizadas de acuerdo con las solicitudes de cambios provenientes de los otros planes y dentro de la autonomía
del Product Owner y del patrocinador.
Guía de Referencia Versión 10.0
PAG
 Plan del Proyecto

Nombre Reserva de Contingencia Otras reservas

Product Owner aisladamente Hasta xx.xxx,xx $ Hasta xx.xxx,xx $
Product Owner con el aval del patrocinador Hasta xx.xxx,xx $ Hasta xx.xxx,xx $
Solamente el Patrocinador Superior a de xx.xxx,xx $ y hasta el límite Superior a de xx.xxx,xx $ y hasta el
de las reservas límite de las reservas
Esa autonomía es por solicitud de cambios proveniente de los otros planes, pudiendo, el Product Owner, utilizar la reserva, desde
que sea en diferentes solicitaciones. Finalizadas las reservas, solamente el patrocinador podrá solicitar y decidir sobre nuevas
reservas, de acuerdo a lo que será presentado a continuación en este plan.

2 GESTIÓN DE CALIDAD

2.1 Métricas y metas de calidad:

Este documento define el Plan de Calidad del proyecto <Nombre del proyecto>, identificando como la calidad de la aplicación y de los
artefactos participantes en la implantación de la solución será garantizada.
Todos los cambios realizados en el plan de calidad originalmente aprobado para el proyecto deben ser solicitados, evaluados y
aprobados formalmente, de acuerdo con el Sistema de Control de Cambios, para que sea posible su implementación.

2.2 Listas de verificación de la calidad:

La tabla a continuación presenta cada artefacto/entrega a ser elaborado en el proyecto. También son presentadas las fases en las
cuales el mismo será elaborado por primera vez y sus respectivos responsables. Son incluidos, en la tabla, los artefactos que serán
entregados al cliente (producto) y los artefactos de proceso. Los artefactos/entregas deben ser colocados en la carpeta del proyecto
para su inspección.
<Incluir, en la tabla a continuación, las entregas específicas del cliente y retirar las que no se aplican a este proyecto>

Artefacto/Entrega Responsable Aprobadores Registro Inspección

Planificación
Cláusula de Apertura del Scrum Master Product Owner Documento firmado
Proyecto
Plan de Proyecto Scrum Master Product Owner Documento firmado
Requisitos de Entrega Scrum Master Product Owner Documento firmado
Matriz de Responsabilidades Scrum Master Product Owner Documento firmado
Matriz de Comunicación Scrum Master Product Owner Documento firmado
Matriz de Riesgos Scrum Master Product Owner Documento firmado
Especificación de Procesos Equipo de Implantación Equipo de Implantación Cliente Documentos firmados
“GRUPO”
Plan de Prototipo Equipo de Implantación Equipo de Implantación Cliente Documento firmado
Independiente “GRUPO”
Ejecución
Instalación de producto Scrum Master Product Owner Documento firmado
Personalización y específicos Scrum Master Product Owner Planilla firmada
Capacitación Equipo de Implantación Equipo de Implantación Cliente Evaluación de reacción y
“GRUPO” lista de presencia
Parametrización y registros Equipo de Implantación Equipo de Implantación Cliente Documento firmado
“GRUPO”
Guía de Referencia Versión 10.0
PAG
 Plan de Proyecto

Validación de la base de datos Equipo de Implantación Product Owner Documento firmado

“GRUPO” Equipo de Implantación Cliente
Prototipo Independiente Equipo de Implantación Product Owner Plan de prototipo
“GRUPO” Equipo de Implantación Cliente independiente con los
resultados de las pruebas
homologados
Plan de cambio Equipo de Implantación Equipo de Implantación Cliente Documento firmado
“GRUPO” Product Owner
Scrum Master
Cierre
Cláusula de Cierre Scrum Master Product Owner Documento firmado
Lecciones aprendidas Scrum Master Equipo de Implantación “GRUPO” Documento firmado
Transición de proyecto Scrum Master Product Owner Documento firmado
Monitoreo y Control
Gráfico Burn Down Scrum Master Product Owner Documento firmado
Cuadro de Actividades Scrum Master Product Owner Documento firmado
Equipo de Implantación Equipo de Implantación Cliente
“GRUPO”
Acta de reunión Scrum Master Product Owner Documento firmado
Validación de procesos Scrum Master Product Owner Documento firmado

3 Cambios, acciones correctivas y acciones preventivas en las normas de calidad establecidas y aprobadas:
<Evaluar porte del proyecto – Relacionar solicitaciones de correcciones y acciones preventivas aprobadas para proyecto>

● Políticas de encaminamiento de problemas y acciones correctivas

Las No Conformidades, identificadas en las inspecciones y auditorias, serán registradas por intermedio del sistema de gestión de
cambios y encaminadas al Product Owner para las providencias correspondientes.

3.1 Reglas para mediciones de control de calidad de las entregas:

● Las métricas de calidad presentadas en la tabla a continuación indican los parámetros para la evaluación del resultado de las
inspecciones y auditorias.

<Relacionar las métricas a ser aplicadas en el proyecto, de acuerdo con el modelo presentado a continuación >

Métrica Valores Posibles Interpretaciones Orientación para medición y

análisis
Nº. No Conformidades 10 % Durante la iteración pueden ser Evaluar el producto
0 al final de la iteración identificadas algunas No siguiendo la especificación
Conformidades que deben ser de la norma utilizada.
corregidas hasta el final de la
iteración.
Cualquier valor diferente de cero
indica la necesidad de ajustar el ítem

Guía de Referencia Versión 10.0

PAG
 Plan del Proyecto

auditado para garantir su calidad.

Plazo de Entrega 10% Debe ser evaluada la variación entre Evaluar el número de días de
el número de días del proyecto y el las entregas de los marcos
número de días de atraso. del proyecto, con base en los
baselines del cuadro de
actividades.
Atendimiento del Alcance 100% Será considerando el banco de Evaluar si fueron atendidos
requisitos y la homologación final del todos los requisitos del
producto. proyecto con base en el
parágrafo del alcance
funcional en el Plan de
Proyecto.
Nr. Inspecciones SQA 10 % Será considerado el calendario de Evaluar si las inspecciones y
inspecciones y las nuevas auditorias planificadas
planificaciones ocurridas durante el fueron realizadas.
proyecto

3.2 Reglas/Actividades relacionadas a la gestión de la Garantía de Calidad:

< Evaluar porte del Proyecto – Relacionar las inspecciones y auditorias planificadas para el proyecto, de acuerdo con el modelo>

Inspecciones y Auditorias:

Las inspecciones y auditorias tienen el objetivo de identificar no conformidades en productos y procesos. Las inspecciones son
revisiones más informales. Generalmente, las mismas son realizadas por el propio equipo responsable por el ítem a ser inspeccionado.

El hecho de descubrir no conformidades, en el ítem inspeccionado, es considerado como un hecho natural. La intención es,
justamente, descubrir y corregir la mayor cantidad de no conformidades posible antes de la auditoria.

Las auditorias deben ser registradas y publicadas en la carpeta del proyecto.

Actividad Tipo Objetivo y Procedimientos Participantes

Revisiones del Proyecto Inspección Serán verificados los artefactos Documentación del
(bajo demanda) elaborados durante la ejecución del Proyecto, para cada uno de
proyecto. los documentos elaborados
La inspección Técnica debe y que necesiten de
considerar si las normas fueron inspección o verificación.
utilizadas adecuadamente.
La Inspección Funcional debe
considerar si lo que está descrito,
bajo el punto de vista del negocio, es
coherente, completo y claro.
Las inspecciones son realizadas
durante todo el ciclo de
implantación, de acuerdo con lo
descrito en el tópico 3 -
Documentación del Proyecto.
Revisión de Requisitos Auditoria Verificar la integridad entre las Equipo de Proyecto - (Ver
(de acuerdo con el cuadro de informaciones del Proyecto Matriz de
(documentación y negocio) Responsabilidades)
Guía de Referencia Versión 10.0
PAG
 Plan de Proyecto

actividades) Solicitaciones de cambios.

Revisión de Gestión Auditoria Verificar las revisiones periódicas en Equipo de Proyecto - (Ver
(de acuerdo con el cuadro de los planes de proyecto y la Matriz de
actividades) rastreabilidad de las informaciones, Responsabilidades)
así como el impacto de estas
alteraciones en el proyecto y en el
producto.
Acompañamiento del Proyecto y
ejecución de acciones correctivas.

3.3 Proceso para registrar errores y problemas:

< Presentar una norma para el registro de problemas encontrados en el proyecto – Recomendación para actas de Reunión o lista de
pendencias >

3.4 Reglas para cuestiones de calidad no previstas en este plan:

(Evaluar porte del Proyecto)
<Evaluar la necesidad de definir Reglas para la elaboración de nuevos criterios de aceptación o nuevas pruebas, no previstas
inicialmente, así como sus impactos.>

4 GESTIÓN DE PERSONAL

4.1 Matriz de atribución de responsabilidades:

< Hacer referencia al documento MIT534 - Matriz de Responsabilidades >

4.2 Funciones, autoridad, responsabilidad y competencias necesarias para los miembros del proyecto:
<Hacer referemcia al documento MIT534 – Matriz de Responsabilidades>

Funciones y responsabilidades de los integrantes del Equipo de Proyecto:

● Product Owner:
o Adopta postura más activa en relación al proyecto
o Se esfuerza para entender la solución y sus beneficios (personales y de negocio)
o Controla y ejecuta las actividades designadas
o Actúa con el equipo de implantación brindando informaciones y validando productos
o Decide sobre cambios y sus impactos
o Se compromete con los plazos y resultados de proyecto

● Scrum Master:
o Controla el progreso del proyecto con más frecuencia/proximidad
o Controla el alcance de forma criteriosa
o Actúa como facilitador, removiendo obstáculos y administrando la relación con el cliente
o Protege el equipo para garantizar el objetivo en las actividades del proyecto
o Mide la performance del equipo y garantiza la discusión y utilización de las lecciones aprendidas

Guía de Referencia Versión 10.0

PAG
 Plan del Proyecto

● Equipo de Implantación:
o Responsable por el cumplimiento de los plazos acordados con el cliente
o Busca, de forma permanente, alternativas para la mejora de la calidad y performance
o Reporta la evolución de los trabajos de forma consciente y profesional
o Posee madurez para autogestión, objetivando la entrega
o Reporta prontamente obstáculos al desarrollo de los trabajos

Funciones y Responsabilidades de Integrantes adicionales –”GRUPO”:

● Gestor de Atención y Relación

o Será responsable por la gestión de una cartera de clientes.
o Acompañará, gerencialmente, todas las acciones con los clientes.
o Orientará e informará las directrices del trabajo de cada Ejecutivo de Atención y Relación.

● Analista de Software:
o Será responsable por el desarrollo de cualquier personalización (desarrollo específico) del proyecto.

● Analista de Infraestructura:
o Será responsable por la instalación del ERP en el servidor y optimización de sus recursos en comunicación con el Banco de
Datos.
o Responsable por la configuración y setup de los servicios relacionados a la infraestructura del sistema.

● PMO Escritório de Proyectos

o Responsable por la definición de la metodología, coaching, acompañamiento preventivo y auditoria de proyectos.

● GPP - Gerente Portfolio de Proyectos

o Responsable por la gestión de la cartera de proyectos y por el acompañamiento gerencial del proyecto. Es el superior
inmediato de los coordinadores de proyecto. Orienta sobre las prácticas a ser adoptadas y cuida los resultados obtenidos.

● Ejecutivo de Atención y Relación:

o Responsable por la oferta de los productos y servicios, siendo también un canal de comunicación entre las partes, para
cuestiones comerciales.

● Arquitecto de Solución:
o Será el responsable por evaluar nuevas necesidades para el proyecto y aclarar detalles de las necesidades identificadas.
o Será responsable por evaluar y diseñar las soluciones a ser implementadas, de acuerdo con las necesidades apuntadas por el
cliente.
o Actuará, principalmente, en la fase previa del proyecto y en la definición de nuevos frentes de trabajo, cuando sea necesario.

Guía de Referencia Versión 10.0

PAG
 Plan de Proyecto

4.3 Organigrama del Proyecto:

Define el Plan de Equipo del Proyecto, con el objetivo de registrar sus integrantes, sus papeles, responsabilidades e informaciones de
contacto.

<Inserir aqui el organigrama del proyecto>

4.4 Histograma de recursos:

<Evaluar el porte del proyecto. Adjuntar el gráfico del Histograma de asignación de los recursos en el proyecto >

4.5 Necesidad de capacitación identificada:

<Describir alguna necesidad adicional de capacitación para el equipo “GRUPO” o del cliente en el proyecto>.

4.6 Plan para evaluación de desempeño del equipo:

<Hacer Referencia al documento MIT064 - Evaluación Analista por Proyecto.>

4.7 Registro de problemas relacionados al equipo:

<Lista de problemas relacionados a algún miembro del equipo. (Funcional y de comportamiento)>

5 GESTIÓN DE LAS COMUNICACIONES

5.1 Planificación de las Comunicaciones:

Procesos de Gestión de las Comunicaciones

El Plan de Comunicación registra los procedimientos necesarios para garantizar que la información elaborada por el proyecto sea
reunida, administrada y distribuida de forma precisa y adecuada entre sus participantes.
Serán reconocidos como procesos formales de comunicación para este proyecto:
Documentos y reportes previstos en la Metodología de Implantación “GRUPO” – MIT y otros documentos y reportes de apoyo
definidos en común acuerdo entre “GRUPO” y cliente:
● Memorándum;

● E-mails;

● Correspondencias;

● Reuniones (registradas en acta).

Todos los cambios en el proceso de comunicación, originalmente aprobado para el proyecto, deben ser solicitados, evaluados y
aprobados formalmente, en conformidad con el Sistema de Control de Cambios, para ser implementados.

5.2 Reglas y criterios para distribución de las informaciones:

En este tópico se encuentran descritas las actividades de comunicación, referentes a la distribución de las informaciones resultantes de
algunos procesos de gestión y control, que serán desempeñadas durante todo el proyecto.

Guía de Referencia Versión 10.0

PAG
 Plan del Proyecto

5.3 Formato y reglas para comunicar desempeño del proyecto:

Principales Eventos

Los principales eventos de comunicación previstos para el proyecto son:

< Ajustar cuadros de acuerdo con la necesidad del proyecto >

Reunión de Apertura del Proyecto

Objetivo Oficializar el inicio de la ejecución e integrar los participantes del
proyecto
Responsable Scrum Master
Participantes <Listar Participantes>
Método Reunión con la participación de los principales interesados, afectados
y participantes del proyecto, considerando los recursos del cliente y
otras organizaciones, con la realización de un encuentro festivo al
finalizar la misma.
Frecuencia Inmediatamente, al inicio de la fase de ejecución del proyecto
Convocación 1 semana antes de la reunión, por intermedio de e-mail
Duración Definido por el responsable por la convocación (máximo 2 horas)
Local Definido por el responsable por la convocación
Observaciones Es solicitada un acta de reunión con los resultados del Kick off y
cláusula de apertura del proyecto

Reuniones del Comité Ejecutivo (Político) del Proyecto

Guía de Referencia Versión 10.0

PAG
Plan de Proyecto

Objetivo Comunicación y evaluación del desarrollo del proyecto y definición de

acciones que exijan una decisión por parte del Comité Ejecutivo del
proyecto
Responsable Scrum Master y Product Owner
Participantes <Listar Participantes>
Método Reunión con el Comité, con base en el reporte de acompañamiento
del proyecto y análisis de requisiciones de cambio en el proyecto
Frecuencia A cada 15 días, registradas en la pauta de las reuniones de Directorio
del Cliente
Convocación Incluir en la pauta de las reuniones de gerencia por e-mail y contacto
personal
Duración 30 min
Local <Local>
Observaciones En esta reunión deben ser discutidas y aprobadas, o reprobadas, las
solicitaciones de cambio del alcance del proyecto

Reunión Diaria
Objetivo Alineación de los trabajos del equipo para que actúen integrados
durante todo el proyecto.
Registrar, en 15 minutos, lo que cada miembro del equipo hizo desde
la última reunión, lo que pretende hacer hasta la próxima y si hubo
algún obstáculo. Por intermedio de esta reunión el equipo gana
visibilidad para saber cómo está el camino hasta la meta y planifica el
día siguiente de trabajo.
Responsable Equipo de Implantación “GRUPO”
Participantes Equipo de Implantación “GRUPO” y Equipo de Implantación Cliente
< listar participantes >
Método Reunión presencial
Frecuencia Diaria
Convocación Vía e-mail
Duración 15 minutos
Local <Local>
Observaciones Se utiliza el cuadro de actividades con la intención de nivelar y
compartir el conocimiento del Equipo de Implantación y del Scrum
Máster, apuntando los posibles cambios de alcance o riesgos
identificados.

Reunión de Planificación del Ciclo

Objetivo Definir, com el Product Owner, las prioridades a ser incluidas en el
ciclo, o sea, definir las actividades que serán incluidas en el ciclo a ser
iniciado.
Responsable Scrum Master y Product Owner
Participantes < Listar participantes> Equipo de Implantación
Método Reunión para tomar decisiones
Frecuencia Una reunión al inicio de cada ciclo
Convocación Vía e-mail
Duración 8 horas
Guía de Referencia Versión 10.0
PAG
 Plan del Proyecto

Local <Local>
Observaciones

Reunión de Homologación de los Procesos

Objetivo Reunión con la presencia del Equipo de Proyecto para presentar y
aprobar formalmente los procesos definidos y los que serán
implantados.
Responsable Equipo de Implantación
Participantes < Listar participantes >
Método Presentación
Frecuencia Reunión al final de la fase de especificación de procesos.
Convocación Vía e-mail
Duración 8 horas
Local <Local>
Observaciones En esta reunión deben ser firmados todos los documentos generados
en la etapa de “Especificación de Procesos”.

Reunión de Revisión del Ciclo (Sprint Review)

Objetivo Identificar lo que fue realizado y no que realizado durante el ciclo. El Equipo discute sobre
lo que salió bien durante el ciclo y cuáles problemas fueron enfrentados y cómo fueron
resueltos los mismos.
Responsable Scrum Master
Participantes < Listar participantes >
Método Reunión de evaluación del ciclo.
Frecuencia Reunión al final de cada ciclo de proyecto.
Convocación Vía e-mail
Duración 5% del tiempo total del ciclo
Local <Local>
Observaciones
Reunión de Retrospectiva
Objetivo Motivar al equipo para revisar el proceso de trabajo. La finalidad de la retrospectiva es la
de inspeccionar la forma como fue realizado el último ciclo en relación a las personas,
relaciones entre las mismas, procesos y herramientas
Responsable Scrum Master
Participantes < Listar participantes >
Método Reunión de inspección adaptación del equipo
Frecuencia Reunión al final de cada ciclo del proyecto.
Convocación Vía e-mail
Duración 3 horas.
Local <Local>
Observaciones

5.4 Proceso para administrar las comunicaciones con las partes interesadas:
<Hacer referencia al documento MIT535 – Matriz de Comunicaciones>.

Guía de Referencia Versión 10.0

PAG
 Plan de Proyecto

5.5 Reglas para registro de problemas y reclamaciones de las partes interesadas:

Los documentos del proyecto serán almacenados en medios magnéticos y físicos.

La documentación en medio magnético será almacenada en la red del cliente, de acuerdo con la siguiente estructura:
Ejemplo:

\\Desarrollo\Proyecto ABC
\01 – Calificación
\02 - Iniciación
\03 – Planificación
\04 – Ejecución
\05 – Cierre
\06 – Monitoreo y Control
\Actas de Reunión
\Documentos Auxiliares
\Emails

Área en Webdesk “GRUPO”:

Proyecto ABC
150.000
\01 – Calificación
\02 - Iniciación
\03 – Planificación
\04 – Ejecución
\05 – Cierre
\06 – Monitoreo y Control
\Actas de Reunión
\Documentos Auxiliares
\Emails

6 GESTIÓN DE RIESGOS
(Evaluar el porte del proyecto >

“GRUPO”, invariablemente, pretende ofrecer el máximo de seguridad en los proyectos de implantación de sus productos. Con este
objetivo, fue elaborada la Metodología de Implantación “GRUPO” (MIT), modalidad Série 3. Al mismo tiempo, se desea ofrecer el
mismo nivel de calidad de servicio para la efectiva aplicación de nuestros productos, los que poseen, reconocidamente, tecnología de
clase mundial.

Entre tanto, cualquier organización, independientemente de su tamaño y de la profundidad de los cambios a ser realizados en los
proyectos de implementación de softwares de gestión empresarial, debe considerar los factores que participan del mismo,
principalmente los relativos a los recursos humanos, aspectos organizacionales, culturales y los reflejos en la planificación y
operaciones de la empresa. De esta forma, se entiende que hay una clara variación entre la situación corriente y los nuevos niveles
planificados por esta organización, como resultado de este proceso de cambio.

Lo que se debe admitir como definitivo es que este proyecto genera cambios, alteraciones en los procesos, cambios en los papeles de
los colaboradores, modificación en los niveles de responsabilidad y, principalmente, alteración de los límites entre los diferentes
departamentos y estructura de la organización.

Ante estas expectativas, el Comité Ejecutivo y los gestores del proyecto, deben realizar diversas evaluaciones y acompañamiento de los
niveles de riesgo de la organización y del proyecto. En este punto, el destaque principal es acompañar y evaluar el nivel de adherencia
y evolución que el proyecto le permite a la empresa.
Guía de Referencia Versión 10.0
PAG
 Plan del Proyecto

Siendo así, la Organización debe estar preparada para, siempre que sea necesario, ajustar los procesos y también sus políticas y
proveer el crecimiento humano, técnico y profesional de sus recursos, ajustándolos a la nueva realidad y necesidades, expectativas y
metas de la empresa, pretendiendo, con esto, alcanzar el éxito de la implementación, sin los cuales el proyecto podrá ampliar su nivel
de riesgo.
Con esta relación intrínseca, “GRUPO” reconoce la importancia de la Gestión de Riesgos y, por eso, coloca a disposición, para su
gestión, la metodología anteriormente mencionada.

Qué es riesgo?

La gestión de riesgos del proyecto es un proceso sistemático para identificar, analizar, responder y acompañar los riesgos del proyecto.
Deben ser tratados todos los elementos del proyecto: organización, personas, procesos, ambiente y tecnología;

La gestión de riesgos debe ser aplicada durante todo el ciclo de vida del proyecto;

Además, “GRUPO” indica como princípios:

● Como las alteraciones en los proyectos son casi seguras, “GRUPO” y el cliente realizarán el control constante de las
implementaciones y respetarán el “Proceso de Control de Cambios”, el cual es parte integrante del Plan de Proyecto.

● Al ser identificados, los riesgos deben ser comunicados inmediatamente a los miembros del proyecto y los demás participantes,
como el Product Owner. Es responsabilidad del Scrum Master la realización efectiva de esta comunicación, la cual debe realizarse
utilizando la norma de documentación del proyecto, adicionando la respectiva planilla de riesgos con la forma de mitigación y el
respectivo plan de acción.

● La apuración de los riesgos, su análisis y sus planos de acción, deben ser insumos para las lecciones aprendidas durante el
proyecto y deben ser utilizados en el análisis de los riesgos adicionales y complementarios durante el proyecto; o sea, cuando
sean desarrollados nuevos análisis, los anteriores deben ser revisados y evaluada la efectividad de las acciones anteriormente
propuestas.

● Comparta la responsabilidad de los riesgos y de los planes de acción con todo el equipo de proyectos. Los riesgos no tienen
exclusivamente un dueño, pues la responsabilidad es de todo el equipo. Algunas personas pueden ser nominadas para determinar
acciones de acuerdo con los riesgos identificados, pero los riesgos en si son compartidos entre todos.

● La comunicación de los riesgos, al equipo responsable por el proyecto y patrocinadores del mismo, es un factor de gran
importancia. La solución se identifica fácilmente cuando el equipo participa activamente. Es importante recordar que la estima de
las personas se fortalece cuando son invitadas para participar y ayudar a decidir. De esta forma, se comparten las
responsabilidades en los resultados del proyecto.

Estrategia para Gestión de Riesgos

● Compromiso entre “GRUPO” y el cliente para eliminar o, cuando esto no sea posible, disminuir el riesgo, pues admitir la falta de
acción sobre el mismo, claramente, hará que no sea posible concluir el proyecto en el plazo estipulado, con la calidad y
presupuesto planificado.

● La credibilidad del proyecto es fundamental para alcanzar el éxito del proyecto. Por lo tanto, esta cuestión debe ser comunicada a
todos los miembros del proyecto y sus resultados evaluados. Las acciones necesarias serán definidas de acuerdo con los
resultados presentados.

● El cliente debe identificar el significado individual de esta implementación con cada uno de sus colaboradores. Es fundamental
buscar, de acuerdo a la óptica de cada miembro, su papel, los impactos en su carrera, responsabilidades, perspectivas y seguridad
en la organización. Esta visión debe ser tabulada e identificada de forma positiva, o negativa, para el proyecto, buscando, de esa
forma, acciones correspondientes para eliminar o minimizar los riesgos.
Guía de Referencia Versión 10.0
PAG
 Plan de Proyecto

● Las herramientas de Análisis de Riesgo deben ser utilizadas durante todo el proyecto, siendo la primera utilizada al inicio de la fase
de planificación con el propósito de medir el nivel de soporte existente en relación al proyecto.

● Es fundamental que el equipo crea en el proyecto, pues, en el caso contrario, no hay forma para garantizar el éxito del mismo;

6.1 Proceso para identificar los riesgos:

<Evaluar el tipo de abordaje - Citar el tipo de técnica negociada para listar los riesgos. Ver modelo a continuación >

La identificación de los riesgos permite determinar cuáles son los que pueden afectar el proyecto, así como documentar sus
características.

La principal forma de identificación de los riscos de los proyectos es la reunión de acompañamento. A partir de estas reuniones, nuevos
riesgos pueden surgir y los mismos serán acompañados por el Gestor de Proyectos “GRUPO” y por el Gestor de Proyectos delCliente
durante la ejecución del mismo.

Para a identificar riesgos:

● Identificar, con los participantes, los obstáculos del proyecto, sean estos preocupaciones, dificultades en el proyecto,
deficiencias observadas, dificultades en el desarrollo de los trabajos, etc;
● Evalúe, con cada usuario, las posibles causas que originan estos obstáculos;

● Identifique, desde su punto de vista, como se pueden minimizar o eliminar estos obstáculos;

● Identifique, también, como es posible mejorar, o acortar, el proyecto;

● Analice las posibles causas que originan estos obstáculos y relaciónelas a problemas referentes a la Educación y
Capacitación, Reporte jerárquico, falta de conocimiento de la Metodología, etc;
● Verifique, con cada representante del Equipo de Implantación del Cliente, cuales son los beneficios obtenidos al resolver este
obstáculo;
● Analice las informaciones históricas, listas de riesgos ya conocidos, materiales de otros proyectos de la organización, cultura
de la empresa, exigencias legales, etc;
● Determine un responsable para cada riesgo identificado;

● Registre los riesgos en la planilla de riesgos existente en la MIT (MIT036 – Matriz de Riesgos).

6.2 Proceso para calificar y priorizar los riesgos identificados:

<Presentar el template MIT036 – Matriz de Riesgos >

La identificación de los riesgos permite determinar cuáles riesgos pueden afectar el proyecto y documentar sus características.

Clasificación por categorías.

Existen varias formas para hacer efectiva esta clasificación. Es posible considerar los riesgos individuales o personales relacionados a
los participantes del proyecto, riesgos de credibilidad del proyecto, riesgos técnicos relacionados a las herramientas, etc.

● Plazo: atrasos en las fechas de entrega del proyecto y en la ejecución de las actividades.

Guía de Referencia Versión 10.0

PAG
 Plan del Proyecto

● Alcance: aumento del alcance, alcance indefinido, no cumplir el alcance definido, ausencia en la gestión de cambios.

● Costos: aumento de los costos en virtud de problemas con las estimativas o falta de productividad del equipo, aumento del
alcance, trabajo adicional.

● Calidad: uno de los principales factores de riesgo para esta clase son los problemas relacionados a los errores de definición y
construcción. Todavia, como riesgo relacionado a la calidad, es posible identificar que no se ha seguido la metodología
durante el desarrollo, lo que puede derivar en problemas y en la repetición de trabajos en el momento de las inspecciones y
auditorias dela calidad.

● Riesgos de la gestión de proyectos: distribución incorrecta del tiempo y de recursos, calidad inadecuada del plan de
proyectos, utilización incorrecta o falta de conocimiento de las disciplinas de gestión de proyectos.

● Riesgos técnicos y de desempeño: tecnología compleja o no comprobada, metas de desempeño irreal, cambios en la
tecnología o normas de la empresa durante el proyecto.

● Riscos organizacionales: Objetivos de costos, tiempo y alcance que son internamente inconsistentes, falta de priorización de
los proyectos, financiamiento inadecuado o interrupción del mismo y conflicto de recursos con otros proyectos de la
organización.

● Riscos externos: cambios legales, cuestiones laborales, riesgos climáticos, guerras.

Clasifique cada uno de los riesgos con la finalidad de buscar causas y acciones comunes o siga el modelo de categorías presentado en el
template MIT036 – Matriz de Riesgos.

6.3 Proceso para calificar el impacto de los riesgos en los objetivos del proyecto:
< Evaluar el Porte del Proyecto - Presentar los resultados de alguna técnica estadística utilizada >.

El análisis cualitativo de los riesgos es el proceso de evaluación del impacto y probabilidad de los riesgos identificados.

Este proceso prioriza los riesgos de acuerdo con los potenciales efectos sobre los objetivos del proyecto.

Cada uno de los riesgos encontrados para el proyecto debe ser relacionado en la planilla de riesgos y clasificado de acuerdo con las
seguientes características:

● Probabilidad: chance de que el riesgo suceda durante la ejecución del proyecto. La probabilidad es calculada de la siguinte forma:
o De 0,1 a 0,3: probabilidad baja o inexistente;
o De 0,4 a 0,6: probabilidad moderada;
o De 0,7 a 0,9: probabilidad alta.

● Impacto: de acuerdo con la clase de riesgo, cuanto impactará, en el proyecto, en el caso de que el riesgo suceda realmente.
o De 0,1 a 0,3: impacto bajo o inexistente.
o De 0,4 a 0,6: impacto moderado.
o De 0,7 a 0,9: impacto alto.

A partir de estas notas atribuidas se llega al factor de riesgo multiplicando la probabilidad por el impacto. Este factor será
proporcionado por una nota entre 0,01 e 0,81. De esa forma, los riesgos serán clasificados de acuerdo con la tabla presentada a
continuaición:

Guía de Referencia Versión 10.0

PAG
 Plan de Proyecto

Probabil
idad
,1 ,2 ,3 ,4 ,5 ,6 ,7 ,8 ,9
Impacto
0,1 C
,01 ,02 ,03 ,04 ,05 ,06 ,07 ,08 ,09
riticidad
0,2 Baja
,02 ,04 ,06 ,08 ,10 ,12 ,14 ,16 ,18
0,3
,03 ,06 ,09 ,12 ,15 ,18 ,21 ,24 ,27
C
0,4
,04 ,08 ,12 ,16 ,20 ,24 ,28 ,32 ,36 riticidad
Median
0,5
,05 ,10 ,15 ,20 ,25 ,30 ,35 ,40 ,45 a
0,6
,06 ,12 ,18 ,24 ,30 ,36 ,42 ,48 ,54
0,7 C
,07 ,14 ,21 ,28 ,35 ,42 ,49 ,56 ,63
riticidad
0,8 Alta
,08 ,16 ,24 ,32 ,40 ,48 ,56 ,64 ,72
0,9
,09 ,18 ,27 ,36 ,45 ,54 ,63 ,72 ,81

Importante:
El análisis cualitativo de riesgos requiere datos precisos y sin influencias, con la verificación de:

● Entendimiento amplio del riesgo;

● Datos disponibles sobre el riesgo;

● Calidad de los datos;

● Confiabilidad e integridad de los datos

La utilización de datos de baja precisión (Ejemplo: si un riesgo no es bien comprendido) puede llevar a un análisis cualitativo de poco
uso para el Product Owner.

Principales resultados esperados de esa fase: Clasificación de riesgo general del proyecto: la clasificación de riesgos puede indicar la
posición del riesgo global de un proyecto en el caso de que sea comparado con otros proyectos, facilitando las decisiones tomadas y el
objetivo de las acciones.

Lista de riesgos prioritarios: Clasificada en orden decreciente por el Factor de riesgo (P x I), muestra los riesgos que deben tener mayor
atención.

6.4 Reservas para los riesgos identificados:

< Evaluar viabilidad o porte del proyecto - Describir las reservas financieras para los riesgos identificados >

6.5 Reservas para riesgos no identificados:

< Evaluar viabilidad o porte del proyecto - Describir las reservas financieras para los riesgos identificados >
Guía de Referencia Versión 10.0
PAG
 Plan del Proyecto

6.6 Reglas para utilización de las reservas:

<Avaliar viabilidade ou porte do projeto - Descrever o processo para o uso dos recursos reservados >.

6.7 Proceso para planificar respuestas a los riesgos identificados:

<Presentar el documento MIT036 - Matriz de Riesgos >

Es el proceso de desarrollo de opciones y determinación de las acciones para mejorar oportunidades y reduzir amenazas para los
objetivos del proyecto.
A partir de la clasificación de los riesgos, los mismos serán priorizados de acuerdo con el factor de riesgo que recibido por los mismos.
Ítems más críticos son aquellos que recibieron factores más altos. Después de clasificar los riesgos, serán analizados en relación a la
mejor estrategia de tratamiento para los mismos. Como estrategias:

● Aceptar: el equipo acepta convivir con el riesgo. En este caso no será tomada ninguna acción y el riesgo será, solamente,
acompañado. Si el mismo sucede, debe ser elaborado un plan de acción para solucionar el problema generado.

● Eliminar: alcance del proyecto sufre alteraciones, de modo que el riesgo es eliminado. En este caso debe ser elaborado, en el
momento de la planificación, un plan de acción que permita eliminar el riesgo.

● Transferir: se transfiere la responsabilidad del riesgo para alguien que no pertenezca al equipo.

● Evitar: se elaboran estrategias para intentar disminuir la probabilidad de que el riesgo ocurra. En este caso debe ser
elaborado, en el momento de la planificación, un plan de acción que permita evitar el riesgo.

● Mitigar: acciones con el objetivo de reducir el risco a niveles aceptables.

Durante las reuniones semanales con el equipo de proyectos, los riesgos deben ser evaluados nevamente de acuerdo con la situación
actual, en relación a la probabilidad e impacto en el proyecto. En este caso, un nuevo factor de riesgo puede ser atribuido al mismo.
Con base en el análisis de la situación actual, la estrategia de tratamiento del riesgo puede ser alterada y, en el caso de que sea
necesario, debe ser elaborado un plan de acción para el tratamiento del mismo.
Los planes de acción, en la mayoria de los casos, involucran costos, tiempo, recursos, creación de actividades que requieren cambios en
el Plan de Proyecto. Después de analizar los riesgos, y siempre que sea necesario, los planes de proyecto deben ser actualizados.

6.8 Proceso para controlar los eventos de riesgos:

<Presentar el documento MIT036 - Matriz de Riesgos >

O monitoramento e controle dos riscos é o processo de identificar e assegurar o controle do risco, monitorando riscos residuais e
identificando novos riscos, assegurando a execução dos planos do risco e avaliando sua eficiência na redução dos riscos.

Se dertermina que:

● Están siendo implementadas respuestas para los riesgos, de acuerdo a lo planificado

● Las acciones de respuestas al riesgo son eficaces de acuerdo con lo esperado o deben ser elaboradas nuevas respuestas

● Las premisas todavía son validas

Guía de Referencia Versión 10.0

PAG
 Plan de Proyecto

● El análisis de tendencia de la exposición al riesgo modifica las prioridades

● Ocurre un síntoma (gatillo) del riesgo

● Las políticas y procedimientos necesarios son cumplidos y adecuados para acompañar los riesgos

● Se identifican nuevos riesgo

Técnicas utilizadas:

● Auditores de riesgo (responsables por el riesgo) examinan y documentan la eficácia de la respuesta al riesgo

● Revisiones periódicas de los riesgos en las reuniones con el equipo del proyecto

● Análisis de valor agregado e índices de desempeño

Resultados esperados:

● Plan de acción

● Acciones correctivas

● Solicitaciones de cambios en el proyecto, siempre que sea necesario, y actualización de los planes

● Atualización de base histórica de proyectos base utilización em proyectos futuros

6.9 Proceso para registro de los riesgos:

<Presentar el proceso para actualizar el documento MIT036 - Matriz de Riesgos >

EL proceso de conquista del equipo de implantación del proyecto debe ser aplicado como elemento base para moderar los riesgos y
motivar los equipos de trabajo. Siendo así, se debe elaborar un programa que actúe en las causas y consecuencias negativas para el
proyecto y que puedan impedir su conclusión de acuerdo con lo planificado.

Este proceso tiene como objetivo la actuación sobre los individuos, permitiéndoles observar el proyecto en relación a sus aspectos
positivos y trabajar para moderar las causas y efectos negativos.

● La comunicación debe ser amplia y, a su vez, divulgada, siempre, en el menor tiempo posible. Los participantes deben sentirse
privilegiados con las informaciones recibidas. Deben tener la percepción de que son una parte fundamental para el éxito del
proyecto y por esa causa reciben, rápidamente, las comunicaciones correspondientes al mismo;

● Los beneficios del proyecto deben ser ampliamente comunicados, independientemente del tamaño del mismo (pequeño,
mediano o grande). La divulgación correspondiente ayudará para incentivar y percibir que el proyecto está presentando
resultados;

● Los riesgos relacionados a la credibilidad del proyecto serán menores a medida que se consiga disminuir el tiempo de
implementación del proyecto. Cuantos más productos de valor agregado sea posible entregar al Cliente, en el menor plazo
posible, mayores serán los niveles de satisfacción y, consecuentemente, los riesgos de credibilidad del proyecto serán reducidos.
Cuanto mayor sea el plazo del proyecto, menos perceptible serán las ganancias que el mismo puede generar;

Guía de Referencia Versión 10.0

PAG
 Plan del Proyecto

● Es fundamental explicarle al Cliente nuestro nivel de control sobre el proyecto, pues, al presentar nuestra organización, estamos
comunicándole al Cliente que poseemos dominio sobre lo que está siendo implementado y, por lo tanto, existe una percepción
correcta de la reducción de los niveles de riesgos. La Metodología de Implantación “GRUPO” nos orientará sobremanera para
garantizar las normas y organización del proyecto. Siendo así, nunca deje de ejecutar una actividad catalogada como obligatoria
en el desarrollo del mismo. Es muy importante asociar la secuencia y las normas de nuestra metodología con la velocidad
necesaria que será observada por el Cliente.

● Acompañe el equipo de proyectos y verifique el nivel de comprometimiento de cada participante. Este ítem puede representar un
aumento del nivel de riesgos.

● La implementación de un producto de tecnología empresarial seguramente genera algunas complicaciones entre los miembros de
la organización, a medida que los cambios relacionados a su proceso, sus actividades y sus funciones serán alteradas en niveles
más altos o bajos. Como los cambios generan impacto en las actividades corrientes y terminan agregando nuevos conocimientos
en los equipos, consecuentemente exigirán niveles más altos de competencia. Sin la debida gestión, este cuadro puede ser visto
negativamente y, en función de esto, es necesario que el equipo de proyectos responda siempre detallando la planificación del
proyecto, su status, obstáculos encontrados y el respectiva participación de todos los miembros del grupo en la búsqueda de
soluciones alternativas que contribuyan con la retirada de problemas y obstáculos encontrados.

● Al realizar los análisis de riesgos, sus resultados deben ser utilizados para elaborar los respectivos planes de acción, en los cuales
serán abordadas las soluciones para reiniciar el proyecto, tales como: aumento de los niveles de comunicación, capacitaciones,
aumento de energía y personal involucrado en las etapas que poseen atraso etc. Es necesario aclararle, a los participantes, que si
las medidas correctivas y el plan de acción no son seguidos, resultará en perjuicios para el proyecto, poniendo en riesgo la calidad,
plazo y costos planificados para el mismo.

● El gestor de proyectos “GRUPO”, asó como el gestor de proyectos del cliente, deben evaluar las necesidades individuales de cada
participante crítico del proyecto y tentar conciliar estas necesidades con los intereses y metas del proyecto.

● Otro aspecto fundamental es que el cuerpo de gestión de proyectos debe garantizar todo el soporte necesario al equipo de
proyectos.

6.10 Reglas para solicitar cambios en el proyecto en función de la identificación de nuevos riesgos:
Adjunto: Modelo de flujo para control de cambios de riesgos (Risk Change Control System):

Guía de Referencia Versión 10.0

PAG
 Plan de Proyecto

6.11 Reglas para actualizar este plan a partir de cambios en los riesgos:
Ejemplo:
Toda la identificación de riesgos y alteraciones en los mismos, ya identificados (variación en la probabilidad e impacto de los riesgos
debe ser tratada según el flujo presentado a continuación con sus conclusiones presentadas en la reunión semanal de CCB con sus
conclusiones, prioridades y acciones relacionadas).

6.12 Reglas para cuestiones de riesgos no previstas en este plan:

< Evaluar Reglas para riesgos no previstos en el proyecto que deben ser negociadas>

Aprobación:

Guía de Referencia Versión 10.0

PAG
 Plan del Proyecto

Aprobado por: Firma Fecha

<Nombre y Función> ___/___/___

Guía de Referencia Versión 10.0

PAG