Plan de Dirección de Proyecto.

A. Alcance

PLAN DE GESTIÓN DE ALCANCE

Proceso de recopilar requisitos
Antes de determinar el alcance es necesario determinar los requisitos o necesidades de
los interesados. Requisitos:
 Plan de gestió n del alcance
 Objetivos de la organizació n
Se aplicará n entrevistas, cuestionarios a los interesados para documentar los requisitos,
ademá s de creará un prototipo para una retroalimentació n temprana del producto final.
Y finalmente se realizará la matriz de trazabilidad de requisitos.
Proceso de definición del Alcance
La definició n del alcance se realizara a alto nivel. Requisitos:
 Acta de constitució n del Proyecto
 Documentació n de requisitos
Se definirá el alcance del Proyecto y el producto, sus entregables respectivos, y las
tareas necesarias para llevarlas a cabo, también es necesario definir los supuestos del
proyecto para una mejor definició n del alcance.
Proceso de elaboración del EDT
Requisitos:
 Enunciado del alcance
 Documentació n de requisitos
El EDT es como la estructura jerá rquica de todo el trabajo a realizar en el Proyecto, se
descompone el trabajo hasta el mínimo nivel que será el paquete de trabajo.
Cabe resaltar que en el EDT no se definen tareas.
Proceso para validar el alcance
Este proceso debe realizarse al finalizar entregables importantes del proyecto y debe
realizarse siempre antes del proceso de cerrar proyecto o fase. Requisitos:
 Entregables a validar
 Documentació n de requisitos
 Datos de desempeñ o de trabajo
Este proceso consiste en asegurar que cada entregable este cumpliendo con los
requerimientos iniciales del proyecto, el cual se valida con el cliente y sponsor. Esto se
realizara mediante inspecciones o auditorias. También se determinará si es necesario
realizar acciones correctivas
Proceso de controlar el alcance
Este proceso realiza el control de cambios del alcance. Requisitos:
 Línea base del alcance
 Matriz de trazabilidad de requisitos
 Datos de desempeñ o del trabajo
Se realizaran estudios para analizar las desviaciones del alcance con la línea base, se
determinara a partir de esto si es necesario realizar acciones correctivas.
 DOCUMENTACIÓN DE REQUISITOS
Necesidad del negocio u oportunidad a aprovechar
La empresa tiene como objetivos, mejorar la calidad en el servicio brindado, cubriendo
todas las necesidades de sus clientes y también ampliar su cartera de clientes. Por otra
parte se busca la sostenibilidad financiera y lograr ser una empresa competitiva capaz
de enfrentar al mercado rígido existente.

Luego de haber identificado estos objetivos es que se genera la necesidad de la

optimizació n y automatizació n de sus procesos internos, ya que se ha identificado
deficiencias en sus procesos, como soporte tecnoló gico es que se plantea la
implementació n de un Sistema de Informació n.

Ya que en la actualidad la mayoría de empresas ha optado por diseñ ar un Sistema de

informació n propio ya que ven al desarrollo de sistemas como una gran herramienta
tecnoló gica, con el objetivo de obtener un control total sobre los procesos y flujo de
datos dentro de su organizació n, dando soporte también a la toma de decisiones.

Objetivos del negocio y del proyecto

Objetivos de la Organización:
 Incrementar la rentabilidad
 Expandir la cartera de clientes.
 Retenció n de los clientes actuales.
 Optimizar los procesos internos.
 Brindar servicio de calidad.
 Capacitar al personal para desarrollar competencias claves.
 Desarrollar una cultura de trabajo en equipo, de cambio e innovació n en el
personal.
Objetivos del Proyecto
 Objetivo General
 Desarrollar e implementar un sistema que será llamado Sistema de Soporte
Logístico que logre cumplir con los está ndares y lineamientos de la empresa
y satisfacer los requerimientos, como herramienta de soporte a la gestió n
logística de la organizació n.
 Objetivos Específicos
 Se brindará soporte a los procesos del sistema actual, para innovar y
optimizar los procesos existentes.
 Se brindará soporte tecnoló gico, al implementar un sistema de informació n
capaz de automatizar y agilizar los procesos del sistema planteado.
 El sistema de informació n debe administrar, procesar, almacenar y distribuir
la informació n de forma adecuada y eficiente.
 El sistema debe administrar el inventario, gestionar tanto entradas como
salidas. Como consecuencia se obtendrá un Kardex.
 El sistema debe administrar las compras y ventas de la empresa, ya que
mediante ella se generará n las entradas y salidas del inventario.
 Requisitos funcionales
Prioridad
Requisitos
Interesado otorgada por el
interesado Có digo Descripció n
El sistema permitirá automatizar la
Alta R01
gestió n del inventario
Nora Mendoza Vega
El sistema permitirá visualizar todas
(Gerente General de
Alta R02 aquellas salidas y entradas del
Distribuciones Hillary
inventario, mediante un kardex
EIRL)
El sistema permitirá gestionar la
Media R03
informació n de los clientes
El sistema permitirá gestionar las
compras y ventas, las cuales está n
Alta R04
Gabriela Ferná ndez ligadas a las entradas y salidas del
Mendoza kardex
(Secretaria General) El sistema permitirá realizar
Alta R05 reportes para el control adecuado de
los procesos realizados
Requisitos no funcionales
Prioridad
Requisitos
Interesado otorgada por el
interesado Có digo Descripció n
Nora Mendoza Vega
(Gerente General de El sistema debe ser una aplicació n
Alta R06
Distribuciones Hillary de escritorio.
EIRL)
Se utilizará como base de datos SQL
Alta R07
Cristhian Agreda Server Express 2008
Mendoza Todos los entregables del proyecto
(Gerente de Proyecto) Alta R08 deben completarse segú n la
programació n realizada
Requisitos de calidad
Prioridad
Requisitos
Interesado otorgada por el
interesado Có digo Descripció n
Que el sistema cumpla con los
Equipo del Proyecto Alta R09
requisitos funcionales establecidos
Nora Mendoza Vega La calidad del proyecto debe ser
(Gerente General de ó ptima, para lograr la aceptació n
Alta R10
Distribuciones Hillary debe cumplir un 85% de los
EIRL) objetivos trazados.
Criterios de aceptación
Los componentes del sistema a desarrollar deben cumplir con el
Técnicos
100% de lo trazado al inicio.
Los componentes del sistema deben cumplir con los está ndares
De calidad
de calidad de definidos por la empresa
Administrativos Todos los entregables deben ser aprobados por el cliente.
 MATRIZ DE TRAZABILIDAD DE REQUISITOS

Atributos del requisito Trazabilidad hacia:

ESTAD GRADO
OBJETIVOS
CÓ DI PRIORI O DE NECESIDADES, OPORTUNIDADE S, REQUERIMIENTO
DESCRIPCIÓ N Propietario CRITERIO DE ACEPTACIÓ N DEL
GO DAD ACTUA COMPL METAS Y OBJETIVOS DEL NEGOCIO DE ALTO NIVEL
PROYECTO
L EJIDAD
Nora Marisol
El sistema permitirá Mendoza Vega  Optimizar los procesos Objetivo del Cumplir con lo
Permitirá el registro de los
R01 automatizar la gestió n del (Gerente General Alta AC A internos. alcance del requerido por
productos existentes
inventario de Distribuciones  Brindar servicio de calidad proyecto el cliente
Hillary EIRL)
Nora Marisol Cumplir con
El sistema permitirá visualizar
Mendoza Vega Permitirá el registro al de  Optimizar los procesos el objetivo Cumplir con lo
todas aquellas salidas y
R02 (Gerente General Alta AC M entradas y salidas del internos de requerido por
entradas del inventario,
de Distribuciones inventario  Brindar servicio de calidad. alcance para el cliente
mediante un kardex
Hillary EIRL) proyecto
 Optimizar los procesos
Solicitado por el Cumplir con
Es necesario se registre internos. Cumplir con lo
El sistema permitirá gestionar Gerente de el
R03 Media AC A toda informació n  Retenció n de los clientes requerido por
la informació n de los clientes Operaciones alcance del
relacionada al cliente actuales. el cliente
(Cliente) proyecto
 Brindar servicio de calidad
Es necesario registrar
El sistema permitirá gestionar Gabriela Definido en
todas las ventas y compras,  Optimizar los procesos Cumplir con lo
las compras y ventas, las cuales Ferná ndez el
R04 Alta AC M y que se generen internos requerido por
está n ligadas a las entradas y (Secretaria alcance del
automá ticamente salidas y  Brindar servicio de calidad. el cliente
salidas del kardex General) proyecto
entradas
El sistema permitirá realizar Gabriela El sistema permitirá Definido en
 Optimizar los procesos Cumplir con lo
reportes para el control Ferná ndez realizar reportes para el el
R05 Alta AC A internos requerido por
adecuado de los procesos (Secretaria control adecuado de los alcance del
 Brindar servicio de calidad. el cliente
realizados General) procesos realizados proyecto
R06 El sistema debe ser una Nora Marisol Alta AC M La aplicació n de software  Optimizar los procesos Definido en Cumplir con lo
aplicació n de escritorio. Mendoza Vega deberá ser basado en internos el requerido por
(Gerente General plataforma de escritorio alcance del el cliente
 Atributos del requisito Trazabilidad hacia:
ESTAD GRADO
OBJETIVOS
CÓ DI PRIORI O DE NECESIDADES, OPORTUNIDADE S, REQUERIMIENTO
DESCRIPCIÓ N Propietario CRITERIO DE ACEPTACIÓ N DEL
GO DAD ACTUA COMPL METAS Y OBJETIVOS DEL NEGOCIO DE ALTO NIVEL
PROYECTO
L EJIDAD
de Distribuciones
proyecto
Hillary EIRL)
Cristhian Agreda Definido en
Utilizar como motor de Cumplir con lo
Se utilizará como base de datos Mendoza  Optimizar los procesos el
R07 Alta AC M base de datos SQL server requerido por
SQL Server Express 2008 (Gerente de internos alcance del
Express 2008 el cliente
Proyecto) proyecto
Todos los entregables del Cristhian Agreda Definido en
Todos los entregables Cumplir con lo
proyecto deben completarse Mendoza  Optimizar los procesos el
R08 Alta AC A deben ser culminados requerido por
segú n la programació n (Gerente de internos alcance del
segú n cronograma el cliente
realizada Proyecto) proyecto
El producto final debe Definido en
Que el sistema cumpla con los  Optimizar los procesos Cumplir con lo
Equipo del cumplir con todos los el
R09 requisitos funcionales Alta AC A internos requerido por
Proyecto requisitos definidos en el alcance del
establecidos  Brindar servicio de calidad el cliente
alcance proyecto
Nora Marisol
La calidad del proyecto debe ser Definido en
Mendoza Vega  Optimizar los procesos Cumplir con lo
ó ptima, para lograr la El sistema debe lograr la el
R10 (Gerente General Alta AC A internos requerido por
aceptació n debe cumplir un satisfacció n del cliente alcance del
de Distribuciones  Brindar servicio de calidad el cliente
85% de los objetivos trazados. proyecto
Hillary EIRL)
 ENUNCIADO DEL ALCANCE DEL PROYECTO
Descripción del alcance del producto
Requisitos Características
I. Sera posible realizar consultas, insertar
nuevos productos, actualizar stock y dar
I. El sistema permitirá automatizar la
de baja a determinados productos.
gestió n del inventario mediante un
II. Sera posible realizar consultas sobre
kardex.
todas las entradas y salidas del
inventario.
II. Sera posible realizar consultas, crear
II. El sistema permitirá gestionar la nuevos clientes (naturales o jurídicos),
informació n de los clientes adjuntado sus datos y dar de baja a
determinados clientes.
III. El sistema permitirá gestionar las IV. Sera posible registrar compras y ventas,
compras y ventas, las cuales está n y para cubrir la necesidad de compras,
ligadas a las entradas y salidas del se permitirá la gestió n de proveedores
kardex (naturales o jurídicos).
V. El sistema permitirá realizar reportes V. Sera posible generar diferentes reportes
para el control adecuado de los o grá ficos que permitan obtener
procesos realizados informació n relevante.
Criterios de aceptación
Los componentes del sistema a desarrollar deben cumplir con el
Técnicos
100% de lo trazado al inicio.
Los componentes del sistema deben cumplir con los está ndares
De calidad
de calidad de definidos por la empresa
Administrativos Todos los entregables deben ser aprobados por el cliente.
Descripción del alcance del proyecto
Desarrollar e implementar un sistema que será llamado Sistema de Soporte Logístico
que logre cumplir con los está ndares y lineamientos de la empresa y satisfacer los
requerimientos, como herramienta de soporte a la gestió n logística de la organizació n.
Fases del proyecto
Fase Descripción
En esta fase se realiza el modelamiento
empresarial, para determinar el sistema
Incepción
actual y realizar el aná lisis correspondiente
para determinar los requisitos.
En esta fase se realiza un aná lisis del
sistema propuesto, se documenta la
Elaboración arquitectura de la aplicació n y se desarrolla
algunos prototipos de la interfaz de la
aplicació n.
Esta fase se pasa a la etapa de desarrollo,
que es la construcció n del sistema segú n la
arquitectura ya diseñ ada, se obtiene una
Construcción
versió n beta al finalizar y realiza las
respectivas pruebas para realizar la
retroalimentació n respectiva
Transición Esta fase se realiza el despliegue de la
aplicació n o también llamada la puesta en
producció n, ademá s se provee asistencia y
 capacitació n a los usuarios para el uso de la
herramienta.
Esta fase comprende todo el proceso de
Gestión de proyectos gestió n de proyectos, desde la iniciació n del
proyecto hasta el cierre del mismo.
Entregables del proyecto
 Modelamiento empresarial
Incepción
 Lista de requisitos
 Modelo de diseñ o
 Modelo de datos
Elaboración
 Documento de arquitectura de software
 Plan de desarrollo de software
 Versió n ú til Beta del sistema
 Có digo fuente
Construcción  Reportes de pruebas
 Documentar defectos
 Checklist de verificació n de
funcionalidad del sistema.
 Reporte de despliegue del sistema
Transición  Manual de usuario
 Reportes de capacitació n al usuario
 Acta de Constitució n del Proyecto
 Plan de Gestió n del Proyecto
 Acta de Reunió n
 Solicitudes de Cambio
Gestión de proyectos  Lista de riesgos
 Plan de gestió n de requerimientos
 Plan de control de cambios

 Acta de cierre del proyecto

Restricciones del proyecto

Ambientales o externos a la
Internos a la organización
organización
La inversió n que se realice para cada Otros gastos no asociados y/o no
actividad deberá ser limitada a la presupuestados afectará n en la fecha de
planeació n de costo acordada con el entrega final de la implantació n del
sponsor. sistema.
La ejecució n del proyecto debe realizarse El no proveer facilidades al equipo del
ú nicamente por el equipo conformado por proyecto impactará de forma directa en el
los integrantes del proyecto y miembros desarrollo del proyecto.
que el Director de Proyecto haya
determinado.
La implantació n del sistema solo podrá En caso de existir situaciones de riesgo
ser llevada a cabo en horario laboral, el externo que requieran la suspensió n de
cual es de lunes a viernes de 8 a 12 pm y actividades del local y/o dictadas por ley,
de 2 a 6 pm. Se encuentran excluidos los podrá afectar a la continuidad del
días no laborales designados por ley. proyecto.
Supuestos del proyecto
Ambientales o externos a la
Internos a la organización
organización
 Se cuenta con los medios de comunicación
verbal y escrita entre los miembros del
equipo del proyecto y los integrantes de la
organización.
Se cuenta con personal técnico con
experiencia para la toma de requerimientos
del proyecto
Se cuenta con personal técnico con
experiencia suficiente para la ejecución de
sus tareas.
Se dispondrá de toda la información
relacionada a la organización para el análisis
del sistema actual.
- EDT
La empresa Distribuciones Hillary EIRL
cuenta con la infraestructura necesaria para
generar el ambiente de prueba y el
despliegue final.
El sponsor debe participar en la revisión de
entregables según se vayan realizando, para
realizar la validación del alcance.
Las personas responsables de aprobar los
entregables se sujetarán a los plazos
establecidos en el Plan de Proyecto.
Las capacitaciones se realizarán de acuerdo a
un cronograma, y éstas serán únicas por
implantación.
 B. Tiempo

PLAN DE GESTIÓN DEL TIEMPO

Proceso de definición de actividades
Antes de determinar el cronograma es necesario definir las actividades. Requisitos:
 Plan de gestió n del tiempo
 Línea base del Alcance(Enunciado del alcance, EDT)
Se descompondrá los paquetes de trabajos establecidos en el EDT para determinar
las actividades y ademá s los hitos que generalmente son entregables del proyecto.
Proceso de secuenciar, estimar las actividades
Luego de determinar las actividades es necesario secuenciarlas. Requisitos:
 Plan de gestió n del tiempo
 Lista de actividades
Para determinar la secuencia de las actividades, se realizará un diagrama de red del
cronograma y la ruta crítica del proyecto
Proceso de desarrollar el cronograma
Requisitos:
 Plan de gestió n del tiempo
 Diagramas de red
 Duració n de actividades
Se creará el cronograma segú n los datos ya obtenidos, y será n modelados en el MS
Proyect para su visualizació n respectiva.
Proceso de controlar el cronograma
Requisitos:
 Cronograma
 Datos de desempeñ o del trabajo
Se realizaran estudios para analizar las desviaciones del cronograma con la línea
base, aná lisis de desempeñ o, se determinara a partir de esto si es necesario realizar
acciones correctivas y predicciones del proyecto.

Lista de Hitos

Hito Fecha
Acta de Constitució n del Proyecto 19/08/2014
Plan de Gestió n del Proyecto 01/09/2014
Plan de Ingeniería del Proyecto 25/06/2015
Concepció n (Inicio) 04/11/2014
Concepció n (Fin) 14/11/2014
Elaboració n (Inicio) 18/11/2014
Elaboració n (Fin) 05/12/2014
Construcció n (Inicio) 09/12/2014
Construcció n (Fin) 12/03/2015
Transició n (Inicio) 17/03/2015
Transició n (Fin) 25/06/2015
Acta de Cierre del Proyecto 04/12/2015
Cronograma de actividades
 C. Costos

NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO

Sistema de Soporte Logístico – Distribuciones Hillary SSL

INTRODUCCIÓN:
El fin de este plan de gestión de costos es definir cómo será gestionado los costos asociados con el
Proyecto. Para completar este proyecto con éxito dentro del límite de presupuesto asignado, todos los
miembros clave del proyecto y los interesados deben cumplir con el trabajo definido dentro de este
plan de gestión de costos y del plan general del proyecto que apoya.

ALCANCE:
El plan de gestión de costos para el proyecto incluye la construcción de varios componentes de los
costos, tales como:

 Gestión de proyecto de los recursos del equipo.

 Reclutamiento y contratación de personal adicional, si fuera necesario.

FUNCIONES Y RESPONSABILIDADES DENTRO DE LA GESTIÓN DE COSTOS:

SPONSOR DEL PROYECTO
El Sponsor del proyecto es el responsable de la aprobación del plan del Proyecto de la gestión de costos.
Además, el Sponsor es el responsable de aprobar el presupuesto del proyecto y es la autoridad de
aprobación de los fondos adicionales que puedan ser necesarios.
GERENTE DE PROYECTO
El Gerente del Proyecto para el Proyecto SSL es el responsable de la gestión diaria de los fondos del
proyecto.
El Gerente de Proyecto es el responsable del desarrollo de la estructura de trabajo descomposición
interna (EDT), que cubre todos los trabajos a realizar por el equipo de trabajo.
El Gerente de Proyecto está autorizado para ejecutar el gasto de los fondos del proyecto cuando sea
necesario de acuerdo con el plan de gestión de costos y presupuesto asignado del proyecto.
El Gerente de Proyecto no podrá autorizar el uso de fondos adicionales sin la aprobación previa del
Sponsor del proyecto.

EQUIPO DEL PROYECTO

El equipo del proyecto es el responsable de ejecutar el trabajo asignado, de acuerdo con el plan de
gestión de costos.

PLANEAMIENTO DE GESTIÓN DE COSTOS:

COSTO DE PLANIFICACIÓN Y ESTIMACIÓN
Una vez que las necesidades del Proyecto SSL han sido determinadas, el equipo del proyecto definirá
los recursos necesarios y las necesidades de personal, si fuera necesario, para el buen fin del proyecto.
Con base en los costos laborales y la duración prevista de cada elemento de la EDT, se hará una
estimación determinada.
Los costos de los elementos del EDT serán totalizados y serán usados para solicitar la financiación del
proyecto.
Una vez que el presupuesto del proyecto es aprobado, el sponsor del proyecto comparará la asignación
para cada elemento del EDT contra el presupuesto general y realizará los ajustes en las asignaciones
según sea necesario para cumplir con el presupuesto del proyecto.
Una vez que todas las asignaciones han sido revisadas y aprobadas por el Sponsor del proyecto, se
define la línea base del costo del proyecto.
La línea base de costo del proyecto sólo podrá ser modificada con la autorización del Sponsor del
proyecto.

COSTO DE SEGUIMIENTO
Los trabajos realizados por los miembros del equipo del proyecto deberán ser actualizados en el
cronograma de trabajo.
El Gerente del proyecto calculará los costos reales para todas las categorías de costos y elementos del
EDT y comparará estos costos con los costos reales de la línea base proyectada sobre una base
semanal.
Estas comparaciones se utilizan para generar los datos para todas las métricas e informes de estado.
MEDIDAS DE COSTOS Y GENERACIÓN DE INFORMES
A fin de medir el desempeño del proyecto, se utilizarán varias métricas para capturar los costos y el
rendimiento del cronograma para el Proyecto SSLG.

Las siguientes mediciones serán recogidas y transmitidos por el Gerente del Proyecto:

 Índice de rendimiento de costo (CPI).

 Índice de Rendimiento del Cronograma (SPI).
 Los umbrales de control de CPI y SPI son las siguientes:
o Amarillo: dentro de +/- 20% deben ser reportados al Sponsor del proyecto. Si se
determina que no hay ningún efecto sobre la
línea de base del proyecto no se necesitará que se ejecute una medida necesaria.
o Rojo: mayor de +/- 20% deben ser reportados al Sponsor del proyecto. Las medidas
correctivas se deben tomar para mover el
proyecto de nuevo a un nivel de rendimiento aceptable.

Valor Ganado Frecuencia de los

Amarillo Rojo
métricas informes
CPI Mensual 0,8 ≤ CPI ≤ 1,2 CPI <0,8 o CPI> 1.2
SPI <0,8
SPI Mensual 0,8 ≤ SPI ≤ 1,2
SPI> 1.2
 Variación de los gastos (CV).
 Variación del cronograma (SV).

Una tabla se creará para cada uno de los parámetros anteriores. El Gerente del proyecto presentará
estos cuadros para el Sponsor del proyecto en de Situación del proyecto.
MEDIDAS DE CONTROL DE COSTOS
Si el Proyecto SSL supera sus límites definidos para los indicadores del CPI o del SPI en cualquier
momento, las medidas correctivas serán consideradas e implementadas con el fin de llevar el proyecto
de nuevo en un rango aceptable de rendimiento.
El Gerente de Proyecto y el equipo considerará todas las medidas de control que resulten de la
corrección de los resultados del proyecto.
Un análisis detallado de todas las medidas de control se presentará al Sponsor del proyecto.
El análisis consistirá en:
• Descripción general de las medidas de control.
• El personal que participa.
• Línea de tiempo a implementar.
• Problemas o preocupaciones respecto a la implementación.
• Efecto esperado sobre el desempeño del proyecto.

Las medidas de control serán revisados por el Sponsor del proyecto. Tras la aprobación del Sponsor del
proyecto, el Gerente de proyecto liderará la implementación de la medida de control autorizado. El
Gerente del proyecto también deberá completar todas las solicitudes de cambio requeridas de acuerdo
con el proceso del proyecto de control de cambios.

En algunos casos aislados puede ser necesario para un proyecto recalcular la línea de base de costos.
Todos los esfuerzos se deben tomar para evitar esto. Sin embargo, si es necesario, sólo el Sponsor del
proyecto puede autorizar esta acción.

TIPOS DE COSTOS CONSIDERADOS:

COSTOS DIRECTOS :
Personal : S/. 9932
COSTOS INDIRECTOS :
Materiales : S/. 1500

TOTAL COSTOS : S/. 11432

RESERVA DE CONTINGENCIA : S/. 2000
RESERVA DE GESTIÓN : S/. 3000

TOTAL GENERAL : S/. 16432

Estimación de costos de las actividades del proyecto.
 NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO

SISTEMA DE SOPORTE LOGISTICO – DISTRIBUCIONES HILLARY SSL

Fase Sub-Fase Entregable Costos (S/.)

Project Charter 0.00
Iniciación Alcance preliminar 0.00
Sub-Total Sub-Fase 0.00
Ingeniería de proyecto: Metodología
0.00
Rup
Planificación Plan de Proyecto 0.00
Sub-Total Sub-Fase 0.00
Plan de ejecución del proyecto 0.00
Gestión del Proyecto
Ejecución Plan para el aseguramiento de calidad 0.00
Sub-Total Sub-Fase 0.00
Plan de control de trabajo 0.00
Control
Documento de restricciones 0.00
Acta de Aceptación 0.00
Cierre Documente de cierre del Proyecto 0.00
Sub-Total Sub-Fase 0.00
Sub-Total Fase 0.00
Documento de identificación de
requisitos
640.00
Incepción
Modelamiento empresarial

Sub-Total Sub-Fase 640.00

Documento de diseño y modelamiento 1152.00

Elaboración
Sub-Total Sub-Fase 1152.00
Ingeniería de proyecto
Versión beta del sistema. 6760.00

Construcción Documento de implementación y

548.00
pruebas del sistema.
Sub-Total Sub-Fase 7308.00
Manuales de usuario y configuración 832.00
Transición
Sub-Total Sub-Fase 832.00
Sub-Total Fase 9932.00
TOTAL GENERAL PERSONAL 9932.00
OTROS COSTOS 1500.00
RESERVA DE CONTINGENCIA 2000.00
LINEA BASE DE COSTOS 13432.00
RESERVA DE GESTIÓN 3000.00
PRESUPUESTO DEL PROYECTO 16432.00
 D. Calidad

PLAN DE GESTIÓN DE LA CALIDAD

Política de Calidad del Proyecto:

El proyecto será evaluado con está ndares de Calidad. Así mismo culminar el proyecto en el
tiempo y el presupuesto planificados previamente.

LÍNEA BASE DE CALIDAD DEL PROYECTO

Factor de Frecuencia y
Objetivo de Métrica a Frecuencia y
calidad momento de
calidad utilizar momento de medició n
relevante medició n
SPI = Schedule
Performance * Frecuencia
SPI > = 0.90 Performance * Frecuencia Mensual
del Proyecto Mensual
Index Acum.

CPI = Cost
Performance * Frecuencia
CPI > = 0.90 Performance * Frecuencia Mensual
del Proyecto Mensual
Index Acum.

Hitos = 90%
Cumplimient Cumplimiento de * Frecuencia
de * Frecuencia quincenal
o de los hitos hitos. quincenal
cumplimiento.
* Frecuencia, cada
* Frecuencia, cada vez vez que haya
que haya reunió n con el reunió n con el
Rango del 85%
Grado de % de Grado de Comité Ejecutivo. Comité Ejecutivo.
al 100% de
satisfacció n Satisfacció n. * Medició n, cada vez que * Medició n, cada
satisfacció n
haya reunió n con el vez que haya
Comité Ejecutivo. reunió n con el
Comité Ejecutivo.

PLAN DE MEJORA DE PROCESOS

1. Delimitar el proceso.
2. Definir la oportunidad de mejora.
3. Obtener informació n sobre el proceso observado.
4. Analizar la informació n relevada.
5. Definir las acciones correctivas para mejorar el proceso.
6. Aplicar las acciones correctivas.
7. Verificar si las acciones correctivas han sido efectivas.
8. Estandarizar las mejoras logradas para hacerlas parte del proceso.

LÍNEA BASE DE CALIDAD DEL PRODUCTO

 Proceso Indicador Descripción
Tiempo transcurrido desde el momento que
% de tiempo del ciclo total de
un cliente interno pone pedido hasta que es
un pedido
entregado.
Proceso de
Cantidad de pedidos realizados/ Pedidos
Inventario % de pedidos entregados
solicitados
Pedidos generados sin problemas/ Total de
% de la calidad en los pedidos
pedidos
% de tiempo del ciclo de la Tiempo de respuesta y entrega por parte de
Proceso de orden de compra los proveedores
Compras % de tiempo del ciclo de las Tiempo transcurrido cuando se realiza
devoluciones devoluciones a los proveedores
Tiempo transcurrido durante la venta,
% de tiempo del ciclo de una
Proceso de Ventas desde que un cliente solicita un insumo
venta
hasta que se entrega, factura.
PROCESOS DE GESTIÓ N DE LA CALIDAD:
Para asegurar la calidad se realizará un monitoreo constante acerca de los
indicadores del proyecto y las métricas respectivas.
Estos resultados se analizará n y se remitirá n al responsable para que coordine las
Enfoque de acciones respectivas las cuales también será monitoreada vía los informes
aseguramient semanales en las reuniones de calidad. Las cuales derivarían en Solicitudes de
o de cambio.
la calidad De esta manera lograremos un control efectivo y acciones tempranas ante
cualquier necesidad de mejora de procesos.
Verificando que las solicitudes de cambio realizadas se han cumplido con las
recomendaciones entregadas.

Las acciones sobre el Control de Calidad de los entregables se efectuará n a manera

Enfoque de de control, si los mismos está n conformes a las especificaciones realizadas y ante
control de la situaciones de desviaciones detectadas se realizará las acciones para establecer la
calidad causa raíz y así eliminar las fuentes de error y los resultados será n formalizados
con acciones necesarias.

Cada vez que se requiera mejorar un proceso realizaremos los siguientes pasos:
1. Delimitar el proceso

2. Definir la oportunidad de mejora

Enfoque de 3. Obtener informació n sobre el proceso observado
mejora de 4. Analizar la informació n levantada
procesos 5. Definir las acciones correctivas para mejorar el proceso
6. Aplicar las acciones correctivas
7. Verificar si las acciones correctivas han sido efectivas
8. Estandarizar las mejoras logradas para hacerlas parte del proceso
 E. Recursos Humanos

NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO

SSL
Sistema de Soporte Logístico – Distribuciones Hillary

Introducción

El plan de gestión de recursos humanos es una herramienta que ayudará en la gestión de las
actividades de los recursos humanos a lo largo de todo el proyecto hasta el cierre.
El plan de gestión de recursos humanos incluye:
- Funciones y responsabilidades de los miembros del equipo durante el proyecto
- Organigrama del Proyecto
- Cuántos recursos se adquirirán

Organigrama del Proyecto:

Nota: Adjuntar Organigrama del Proyecto.

Roles y Responsabilidades:

ROLES /
         
PERSONAS
GP: Gerente DBA: DataBase
  SP: Sponsor Analista Programador
de Proyecto Administrator
ENTREGABLES          
1.0 Gestión del
Proyecto          
1.1 Iniciación          
1.1.1 Project
Charter A R      
1.1.2 Alcance
Preliminar A R      
1.2
Planificación          
1.2.1
Enunciado
Ingenieria de V R      
proyecto
1.2.2 Plan de
proyecto A R      
1.3 Ejecución          
1.3.1 Plan de
ejecucion V R      
delproyecto
1.3.2 Plan de
aseguramiento V R      
de calidad
1.4 Control          
1.4.1 Plan de
control de V R      
trabajo
1.4.2
Documento de V R      
restricciones
1.5 Cierre          
1.5.1 Acta
de aceptación A R      
1.5.2
Documento de
cierre del A R R    
proyecto
2.0 Ingenieria
de proyecto          
2.1 Incepción          
2.1.1
Documento de
identificacion de   V R P P
requisitos
2.1.2
Modelamiento V V R P P
empresarial
2.2
Elaboracion          
2.2.1
Documentos de
diseño y   V R P P
modelamiento
2.3
Construccion          
2.3.1 V V V R R
 Versión beta del
sistema
3.2.2
Documento de
implementación V R P P P
y pruebas del
sistema
2.4 Transicion          
2.3.1
Manual de
usuario y V V R P P
configuracion

Leyenda
R = Responsable
P = Participa
V = Revisa
A = Aprueba
Nota: Adjuntar matriz ram.
Descripción de Roles:

Ver Descripción de Roles – versión 1.0

Nota: Adjuntar formatos de descripción de roles.

Adquisición del Personal del Proyecto:

Ver Cuadro de Adquisición del Personal – versión 1.0

Nota: Adjuntar Cuadro de Adquisición de Personal.
Criterios de Liberación del Personal del Proyecto:
Destino de
Rol Criterio de Liberación ¿cómo?
Asignación
Sponsor Al término del Otros proyectos
proyecto
Gerente del Proyecto Al término del Comunicación del Otros proyectos
proyecto Sponsor
Analista Al término de Comunicación del Otros proyectos
contrato Project
Manager
Programador Al término del Comunicación del Otros proyectos
contrato Project
Manager
Administrador de base de Al término del Comunicación del Otros proyectos
datos contrato Project
Manager
Capacitación, Entrenamiento, Mentoring requerido:
● Siempre se deben aprovechar los proyectos para que los Project Manager más
experimentados hagan mentoring a los menos experimentados, en este caso el Sponsor hará
mentoring al Project Manager para ayudarlo a desarrollar sus habilidades de gestión de
proyectos; asimismo el Project Manager hará mentoring a los especialistas que están bajo su
cargo.
● La empresa deberá capacitar y entrenar al personal que participa en el proyecto, según lo
requiera éste.

Sistema de Reconocimiento y Recompensas:

El Project Manager tiene un Sistema de Incentivo por cumplimiento de las líneas base del proyecto:

1. CPI y SPI al final del proyecto, no menores de 1.0, 20% de bono sobre su remuneración mensual
durante el plazo del proyecto.
2. CPI y SPI al final del proyecto, entre 0.95 y 1.0, 5% de bono sobre su remuneración mensual durante
el plazo del proyecto.
3. Cualquier combinación de los logros anteriores promedia los bonos correspondientes, cualquier
resultado por debajo de 0.95 anula cualquier bono.

Los Miembros del equipo tienen un Sistema de Compensación con 70% de remuneración fija y 30% de
remuneración variable, la cual varía según la siguiente tabla:

1. Entrega de asignaciones: Entregar las asignaciones a tiempo, con peso 50.

2. Calidad de entregables: entregar las asignaciones con las pruebas unitarias realizadas con el mínimo
de errores y fallos, con peso 50.

Cumplimiento de Regulaciones, Pactos, y Políticas:

1. Sólo se deben contratar Ingenieros y personal especialista que cuenten con una acreditación
y que pertenezcan al personal interno de la empresa.
2. Todo el personal de la empresa que participa del proyecto pasará por una Evaluación de
Desempeño al final del proyecto, y dicha evaluación se guardará en su file personal.

Requerimientos de Seguridad:

El traslado de equipos (Laptop, Discos Duros, Cd`s) hacia los locales DISTRIBUCIONES HILLARY EIRL,
genera riesgo de robo o asalto para el personal que traslada el equipo, por tanto se fija como
requerimiento de seguridad que cualquier traslado de equipos debe ser hecho con movilidad (taxi)
pagada por la empresa, para bienestar del personal y de los activos de la empresa.

F.
Descripción de roles:

NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO

SSL
SISTEMA DE SOPORTE LOGISTICO

Nombre del Rol

SPONSOR
Objetivos del Rol:
Es la persona que patrocina el proyecto, es el principal interesado en el éxito del proyecto, y
por tanto la persona que apoya, soporta, y defiende el proyecto.
Responsabilidades: Temas puntuales por los cuales es responsable (¿de qué es
responsable?).
○ Aprobar el Project Charter.
○ Aprobar el Scope Statement.
○ Aprobar el Plan de Proyecto.
○ Aprobar el Cierre del proyecto.

Funciones:
○ Firmar el Contrato del Proyecto.
○ Iniciar el proyecto.
○ Aprobar la planificación del proyecto.
○ Cerrar el proyecto y el Contrato del Servicio.
○ Gestionar el Control de Cambios del proyecto.
○ Gestionar los temas contractuales con el Cliente.
○ Asignar recursos al proyecto.
○ Designar y empoderar al Project Manager.
○ Ayudar en la solución de problemas y superación de obstáculos del proyecto.
Niveles de Autoridad:
○ Decide sobre recursos humanos y materiales asignados al proyecto.
○ Decide sobre modificaciones a las líneas base del proyecto.
○ Decide sobre planes del proyecto.
Reporta a:
A Directorio
Supervisa a:
Gerente de Proyecto
Requisitos del Rol:
Conocimientos: Gestión Estratégica.
Liderazgo.
Comunicación.
Habilidades:.
Solución de conflictos.
Inteligencia emocional.
Experiencia: Experiencia en proyectos de Tecnologías de información.
Otros: Gestión de Portafolios.

Nombre del Rol

GERENTE DE PROYECTO
Objetivos del Rol:
Es la persona que gestiona el proyecto, es el principal responsable por el éxito del proyecto, y
por tanto la persona que asume el liderazgo y la administración de los recursos del proyecto
para lograr los objetivos fijados por el Sponsor.
Responsabilidades:
○ Elaborar el Project Charter.
○ Elaborar el Registro de Stakeholders.
○ Elaborar el Plan de Proyecto.
○ Elaborar el Informe de Performance del Proyecto, Realizar la Reunión y generar las
actas.
○ Elaborar el Informe de Cierre de componentes y Elaborar el Informe de Cierre del
proyecto.
Funciones:
○ Ayudar al Sponsor a iniciar el proyecto.
○ Planificar el proyecto.
○ Ejecutar el proyecto.
○ Controlar el proyecto.
○ Cerrar el proyecto.
○ Ayudar a Gestionar el Control de Cambios del proyecto.
○ Gestionar los recursos del proyecto.
○ Solucionar problemas y superar los obstáculos del proyecto.
Niveles de Autoridad:
○ Decide sobre la programación detallada de los recursos humanos y materiales
asignados al proyecto.
○ Decide sobre la información y los entregables del proyecto.
Reporta a:
Sponsor
Supervisa a:
○ Arquitecto de tecnología
○ Consultor Modulo seguridad, Admisión y Consumos
○ Consultor Modulo de Caja y Facturación
○ Capacitador Módulos de Caja y Facturación
○ Capacitador Módulos de Admisión y Consumos
Requisitos del Rol:
Conocimientos: Gestión de Proyectos según
Qué temas, materias, o especialidades debe conocer, manejar el PMBOK.
o dominar. MS Project.
Liderazgo.
Comunicación.
Habilidades:
Negociación.
Qué habilidades específicas debe poseer y en qué grado.
Solución de Conflictos.
Motivación.
Gestión de Proyectos.
Experiencia:
Procesos de desarrollo de
Qué experiencia debe tener, sobre qué temas o situaciones, y
productos.
de qué nivel.
Aplicaciones ERP.
Otros:
Otros requisitos especiales tales como género, edad, No aplica.
nacionalidad, estado de salud, condiciones físicas, etc.
Nombre del Rol
Analista
Objetivos del Rol:
Es la persona que se encargará del desarrollo de aplicaciones en lo que respecta a su diseño y
obtención de los algoritmos, así como de analizar las posibles utilidades y modificaciones
necesarias de los sistemas operativos para una mayor eficacia de un sistema informático.
Otra misión de estas personas es dar apoyo técnico a los usuarios de las aplicaciones
existentes
Responsabilidades:
○ Analizar las condiciones del negocio.
○ Generar el modelo de negocio.
○ Generar el modelamiento de los procesos.
○ Generar diagramas en UML.
Funciones:
○ Reportar al Gerente del Proyecto las actividades asignadas.
○ Planificar el comportamiento del negocio.
○ Control del diseño del sistema SSPL.
Niveles de Autoridad:
○ Decide sobre el análisis necesario para cumplir con lo asignad.
○ Determina los recursos o requisitos necesarios para la preparación del sistema SSPL.
○ Decide sobre la información y los entregables asignados.
Reporta a:
Gerente de Proyecto
Supervisa a:
Ninguno
Requisitos del Rol:
Modelamiento empresarial.
Conocimientos: Sistemas Operativos
Qué temas, materias, o especialidades debe Base de Datos.
conocer, manejar o dominar. Configuración de Sistema SSPL
Ms Project
Comunicación
Habilidades:
Proactividad
Qué habilidades específicas debe poseer y en qué
Confiabilidad
grado.
Trabajo bajo presión
Experiencia: Analista de sistemas (3 años)
Qué experiencia debe tener, sobre qué temas o
situaciones, y de qué nivel.
Otros:
Otros requisitos especiales tales como género, No aplica.
edad, nacionalidad, estado de salud, condiciones
físicas, etc.

Nombre del Rol

Programador
Objetivos del Rol:
Es la persona que se encargará escribir, depurar y mantener el código fuente del programa
informático SSPL
Responsabilidades:
 ○ Generar código fuente del sistema.
○ Depurar el sistema.
Funciones:
○ Elaboración de la versión Beta del sistema SSL.
Niveles de Autoridad:
○ Decide sobre la estructura del código fuente del sistema.
○ Determina los recursos o requisitos necesarios para la preparación del software.
○ Decide sobre la información y los entregables asignados.
Reporta a:
Gerente de Proyecto
Supervisa a:
Ninguno
Requisitos del Rol:
Desarrollo de aplicaciones en Visual
Conocimientos:
Studio 2010
Qué temas, materias, o especialidades debe
Herramientas de Consulta a Base de datos
conocer, manejar o dominar.
Sistema SSL
Comunicación
Habilidades:
Proactividad
Qué habilidades específicas debe poseer y en qué
Confiabilidad
grado.
Trabajo bajo presión
Experiencia:
Qué experiencia debe tener, sobre qué temas o Programador (4años)
situaciones, y de qué nivel. Trabajo en equipo (2 años)
Otros: No aplica.
Otros requisitos especiales tales como género,
edad, nacionalidad, estado de salud, condiciones
físicas, etc.

Nombre del Rol

Administrador de Base de Datos
Objetivos del Rol:
Es la persona que se encargará de administrar las tecnologías de la información y la
comunicación, siendo responsable de los aspectos técnicos, tecnológicos, científicos,
inteligencia de negocios y legales de bases de datos.
Responsabilidades:
○ Implementar, dar soporte y gestionar bases de datos corporativas
○ Crear y configurar bases de datos relacionales
○ Ser responsables de la integridad de los datos y la disponibilidad
○ Diseñar, desplegar y monitorizar servidores de bases de datos
○ Diseñar la distribución de los datos y las soluciones de almacenamiento
○ Garantizar la seguridad de las bases de datos, incluyendo backups y recuperación de
desastres
○ Planificar e implementar el aprovisionamiento de los datos y aplicaciones
○ Diseñar planes de contingencia
○ Diseñar y crear las bases de datos corporativas de soluciones avanzadas
○ Analizar y reportar datos corporativos que ayuden a la toma de decisiones en la
inteligencia de negocios
○ Producir diagramas de entidades relacionales y diagramas de flujos de datos,
normalización esquemática, localización lógica y física de bases de datos y
 parámetros de tablas
Funciones:
○ Reportar al Gerente del Proyecto las actividades asignadas.
○ Elaborar diseño de la base de datos.
○ Elaborar diagramas sobre la estructura de la base de datos.
Niveles de Autoridad:
○ Decide la estructura de la base de datos.
○ Determina los recursos o requisitos necesarios para la preparación del software.
○ Decide sobre la información y los entregables asignados.
Reporta a:
Gerente de Proyecto
Supervisa a:
Ninguno
Requisitos del Rol:
Análisis de Sistemas.
Conocimientos:
Desarrollo de Software.
Qué temas, materias, o especialidades debe
Herramientas de Consulta a Base de datos
conocer, manejar o dominar.
Módulos del Sistema SSPL
Comunicación.
Proactividad
Habilidades:
Confiabilidad
Qué habilidades específicas debe poseer y en qué
Trabajo bajo presión.
grado.
Oratoria
Dominio de escena
Documentación de procesos (1 año)
Experiencia:
Analista (2 años)
Qué experiencia debe tener, sobre qué temas o
Administrador de BD (1 año)
situaciones, y de qué nivel.
Trabajo en equipo (2 años)
Otros: No aplica.
Otros requisitos especiales tales como género,
edad, nacionalidad, estado de salud, condiciones
físicas, etc.
 F. Adquisiciones:

NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO

SISTEMA DE SOPORTE LOGISTICO SSL

Fecha de inicio Fecha requerida

Fuente de Modalidad de Local de trabajo Costo de
Rol Tipo de Adquisición de de disponibilidad
adquisición Adquisición asignado Reclutamiento
Reclutamiento de personal

Contratación DISTRIBUCIONES
Analista Contratación - 01/09/2013 02/09/2013 Ninguno
HILLARY EIRL
Directa

Contratación DISTRIBUCIONES
Programador Contratación - 18/09/2013 19/09/2013 Ninguno
HILLARY EIRL

Directa
Administrador
DISTRIBUCIONES
de Base de Contratación - Contratación 18/09/2013 19/09/2013 Ninguno
HILLARY EIRL
datos
G. Comunicaciones

NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO

Sistema de Soporte Logístico SSL

Comunicaciones del Proyecto:

Ver Matriz de Comunicaciones del Proyecto – versión 1.0.

Nota: Adjuntar Matriz de Comunicaciones del Proyecto

Procedimiento para tratar Polémicas:

1. Se captan las polémicas a través de la observación y conversación, o de alguna persona o grupo que
los exprese formalmente.

2. Se codifican y registran las polémicas en el Log de Control de Polémicas:

LOG DE CONTROL DE
POLEMICAS
Código de Enfoque de Acciones de Resultado
Descripción Involucrados Responsable
Polémicas Solución Solución Fecha obtenido

3. Se revisa el Log de Control de Polémicas en la reunión semanal de coordinación con el fin de:
● Determinar las soluciones a aplicar a las polémicas pendientes por analizar, designar un
responsable por su solución, un plazo de solución, y registrar la programación de estas
soluciones en el Log de Control.
● Revisar si las soluciones programadas se están aplicando, de no ser así se tomarán acciones
correctivas al respecto.

● Revisar si las soluciones aplicadas han sido efectivas y si la polémica ha sido resuelta, de no
ser así se diseñarán nuevas soluciones.

4. En caso que una polémica no pueda ser resuelta o en caso que haya evolucionado hasta convertirse
en un problema, deberá ser abordada con el siguiente método de escalamiento:

1. En primera instancia será tratada de resolver por el Project Manager, utilizando el método
estándar de resolución de problemas.
2. En segunda instancia será tratada de resolver por el Project Manager, y los miembros
pertinentes del Equipo de Proyecto, utilizando el método estándar de resolución de
problemas.
3. En tercera instancia será tratada de resolver por el Sponsor, el Project Manager, y los
miembros pertinentes del proyecto, utilizando la negociación y/o solución de conflictos.
4. En última instancia será resuelta por el Sponsor o por el Sponsor y el Comité de Control de
Cambios si el primero lo cree conveniente y necesario.

Procedimiento para actualizar el Plan de Gestión de Comunicaciones:

El Plan de Gestión de las Comunicaciones deberá ser revisado y/o actualizado cada vez que:

a. Se apruebe una Solicitud de Cambio que impacte el Plan de Proyecto.

b. Se genere una acción correctiva que impacte los requerimientos o necesidades de
información de los stakeholders.
c. Existan cambios de personal en el equipo de proyecto.
d. Se generen cambios en las asignaciones de personas a roles del proyecto.
 e. Existan cambios en la matriz autoridad versus influencia de los stakeholders.
f. Se generen solicitudes especiales de informes o reportes adicionales.
g. Existan quejas, sugerencias, comentarios o evidencias de requerimientos de información no
satisfechos.
h. Existan evidencias de deficiencias de comunicación interna y con involucrados externos.

La actualización del Plan de Gestión de las Comunicaciones deberá seguir los siguientes pasos:

○ Identificación y clasificación de stakeholders.

○ Determinación de requerimientos de información.
○ Elaboración de la Matriz de Comunicaciones del Proyecto.
○ Actualización del Plan de Gestión de las Comunicaciones.
○ Aprobación del Plan de Gestión de las Comunicaciones.
○ Difusión del nuevo Plan de Gestión de las Comunicaciones.
Guías para Eventos de Comunicación:

GUIA PARA REUNIONES:

● Se debe fijar la agenda con anterioridad.
● Se debe coordinar e informar fecha, hora y lugar con los participantes.
● Se debe empezar puntual.
● Se deben fijar los objetivos de la reunión, los roles (por lo menos el facilitador y el anotador),
los procesos grupales de trabajo, y los métodos de solución de controversias.
● Se debe cumplir a cabalidad los roles de facilitador (dirige el proceso grupal de trabajo) y de
anotador (toma nota de los resultados formales de la reunión).
● Se debe terminar puntual.
● Se debe emitir un Acta de Reunión, la cual se debe repartir a los participantes (previa revisión
por parte de ellos).

GUIA PARA CORREO ELECTRONICO:

● Los correos electrónicos entre el Equipo de Proyecto de SSL y el Cliente deberán ser enviados
por el Project Manager con copia al Sponsor, para establecer una sola vía formal de
comunicación con el Cliente.
● Los enviados por el Cliente y recibidos por cualquier persona del Equipo de Proyecto de SSL
deberán ser copiados al Gerente de Proyecto y al Sponsor (si es que éstos no han sido
considerados en el reparto), para que todas las comunicaciones con el Cliente estén en
conocimiento de los responsables de la parte contractual.
● Los correos internos entre miembros del Equipo de Proyecto de PMI, deberán ser copiados a
la lista Equipo SSL, que contiene las direcciones de los miembros, para que todos estén
permanentemente informados de lo que sucede en el proyecto.

Guías para Documentación del Proyecto:

Guías para Codificación de Documentos.- La codificación de los documentos del proyecto será la
siguiente:
AAAA_BBB_CCC.DDD

Donde: AAAA = Código del Proyecto= ‘PROD’

BBB = Abreviatura del Tipo de Documento= pch, sst, wbs, dwbs, org, ram, etc.
CCC = Versión del Documento=’v1.0’, ‘v2.0’, etc.
DDD = Formato del Archivo=doc, exe, pdf, mpp, etc.
Guías para Almacenamiento de Documentos.- El almacenamiento de los documentos del proyecto
deberá seguir las siguientes pautas:

○ Durante la ejecución del proyecto cada miembro del equipo mantendrá en su máquina una
carpeta con la misma estructura que el WBS del proyecto, donde guardará en las sub-
 carpetas correspondientes las versiones de los documentos que vaya generando.
○ Al cierre de una fase o al cierre del proyecto cada miembro del equipo deberá eliminar los
archivos temporales de trabajo de los documentos y se quedará con las versiones controladas
y numeradas (ver sección Guías para el control de versiones), las cuales se enviarán al Project
Manager.
○ El Project Manager consolidará todas las versiones controladas y numeradas de los
documentos, en un archivo final del proyecto, el cual será una carpeta con la misma
estructura del WBS, donde se almacenarán en el lugar correspondiente los documentos
finales del proyecto. Esta carpeta se archivará en la Biblioteca de Proyectos de Consultores
PMI, y se guardará protegida contra escritura.
○ Se publicará una Relación de Documentos del Proyecto y la ruta de acceso para consulta.
○ Los miembros de equipo borrarán sus carpetas de trabajo para eliminar redundancias de
información y multiplicidad de versiones.

Guías para Recuperación y Reparto de Documentos.-

1. La recuperación de documentos a partir de la Biblioteca de Proyectos de Consultores PMI es
libre para todos los integrantes del Equipo de Proyecto de SSPL.
2. La recuperación de documentos a partir de la Biblioteca de Proyectos de Consultores PMI
para otros miembros de SSPL que no sean del Proyecto requiere autorización del Project
Manager.
3. El acceso a la información del proyecto por parte de personas que no son de Consultores PMI
requiere autorización de Gerencia General, pues esta información se considera confidencial,
tanto para Consultores PMI como para el Cliente.
4. El reparto de documentos digitales e impresos es responsabilidad del Project Manager.
5. El reparto de documentos impresos no contempla el control de copias numeradas.

Guías para el Control de Versiones:

1. Todos los documentos de Gestión de Proyectos están sujetos al control de versiones, el cual
se hace insertando una cabecera estándar con el siguiente diseño:

CONTROL DE VERSIONES
Versión Hecha por Revisada por Aprobada por Fecha Motivo

2. Cada vez que se emite una versión del documento se llena una fila en la cabecera, anotando
la versión, quien emitió el documento, quién lo revisó, quién lo aprobó, a que fecha
corresponde la versión, y por qué motivo se emitió dicha versión.
3. Debe haber correspondencia entre el código de versión del documento que figura en esta
cabecera de Control de Versiones y el código de versión del documento que figura en el
nombre del archivo (ver sección Guía para Codificación de Documentos), según:

AAAA_BBB_CCC.DDD

Donde: AAAA= Código del Proyecto= ‘PROD’

BBB= Abreviatura del Tipo de Documento= pch, sst, wbs, dwbs,org,ram,etc.
CCC= Versión del Documento=’v1.0’, ‘v2.0’, etc.
DDD= Formato del Archivo=doc, exe, pdf,mpp,etc.

F.
 Nivel Responsable
Grupo Metodología Frecuencia de Código de
Información Contenido Formato de de
Receptor o Tecnología Comunicación elemento WBS
Detalle Comunicar
Datos y Documento
comunicación digital
Sponsor,
Iniciación sobre la iniciación Project Project (PDF) vía 1.1.1 Project
Alto Equipo de Una sola vez
del Proyecto del Charter Manager correo charter
Proyecto
proyecto electrónico
Datos preliminares
Documento
Datos preliminares digital
Statement Sponsor,
Iniciación sobre el alcance Project (PDF) vía 1.1.2 Alcance
Scope Alto Equipo de Una sola vez
del Proyecto del Manager correo Preliminar
Proyecto
proyecto electrónico

Planificación
detallada
Documento
del Proyecto:
digital
Alcance, Sponsor, 1.2.1
Plan del Muy Project (PDF) vía
Planificación Tiempo, Costo, Equipo de Una sola vez Enunciado
Proyecto Alto Manager correo
Calidad, RRHH, Proyecto Alcance
electrónico
Comunicaciones,
Riesgos y
Adquisiciones
Actividad Documento
Detallada del Sponsor, digital
Gantt del Muy Project 1.2.2
Planificación proyecto, Tiempos, Equipo de (PDF) vía Una sola vez
Proyecto Alto Manager Cronograma
Hitos, RRHH, Proyecto correo
Costos. electrónico
Acta de
Aceptación de PM/ Informe
Cierre del Aceptación Muy Project 1.4.1 Acta de
Proyecto por parte Cliente / impreso y Una sola vez
Proyecto de Alto Manager Aceptación
del Cliente Sponsor Digital
Entregable
Aceptación de Informe
Cierre del Cierre de Project 1.4.2 Cierre
ambas partes de Alto Cliente impreso y Una sola vez
Proyecto Proyecto Manager del Proyecto
cierre de proyecto digital
 H. Riesgos

PLAN DE GESTIÓN DE RIESGOS

Metodología de gestion de riesgos
Proceso Descripció n Herramientas Fuentes de informacion
Sponsor, líderes funcionales y
Planificar la
Elaborar Plan de Gestió n Analistas Funcionales.
Gestió n del PMBOK
de Riesgos. Gerente de Proyectos y equipo
Riesgo.
de Proyecto.
Identificar qué riesgos Sponsor, líderes funcionales y
Identificació n
pueden afectar el Checklist de Analistas Funcionales.
de los
Proyecto y documentar riesgos. Gerente de Proyectos y equipo
Riesgos.
sus características. de Proyecto.
Definició n de
Sponsor, líderes funcionales y
Aná lisis probabilidad de
Evaluar probabilidad e Analistas Funcionales.
Cualitativo de Impacto Matriz
impacto. Gerente de Proyectos y equipo
Riesgos. de Probabilidad
de Proyecto.
de Impacto.
Sponsor, líderes funcionales y
Planificació n de
Planificar la ejecució n de Analistas Funcionales.
Respuesta a los PMBOK
respuestas a los riesgos. Gerente de Proyectos y equipo
Riesgos.
de Proyecto.
Sponsor, líderes funcionales y
Seguimiento y
Verificar continuamente Analistas Funcionales.
Control PMBOK
la ocurrencia de riesgos. Gerente de Proyectos y equipo
de Riesgos.
de Proyecto.

Listado de Riesgos
Descripció n Herramientas
Mejorar relació n con el sponsor e
Deficiente comunicació n
interesados
Bajo conocimiento de la metodología por parte del
Verificació n de los equipos
equipo de desarrollo
Bajo confianza sobre el rendimiento de los hardware Continua supervisió n de los software
Sistema desfasado de los requerimientos y políticas Continua comunicació n con el equipo del
de la empresa proyecto
Variació n en los costos en la etapa de ejecució n del Constante revisió n de los precios en el
proyecto mercado

Identificación, Estimación y Priorización de Riesgos

Riesgos Impacto Influencia
Deficiente comunicación Alto Alto
Bajo conocimiento de la metodología por parte del equipo de
Alto Alto
desarrollo
Bajo confianza sobre el rendimiento de los hardware Medio Alto
Variación en los costos en la etapa de ejecución del proyecto Bajo Alto
Sistema desfasado de los requerimientos y políticas de la
Alto Alto
empresa
 Registro de interesados
Identificación Evaluación Clasificación
FASE DE INTERNO Apoyo /
ROL EN EL REQUERIMIENTOS INFLUENCIA INTERESADO
Nro. NOMBRE EMPRESA Y PUESTO MAYOR / Neutral /
PROYECTO PRIMORDIALES POTENCIAL CLAVE
INTERÉ S EXTERNO OPOSITOR

Que el proyecto se
DISTRIBUCIONES HILLARY
Mendoza Sponsor del concluya exitosamente Todo el
1 EIRL Fuerte SI Interno Apoyo
Vega Nora proyecto Que el producto optimice proyecto
Gerente General
los procesos internos

Que el proyecto se
Gabriela DISTRIBUCIONES HILLARY
Alta concluya exitosamente Todo el
2 Ferná ndez EIRL Fuerte SI Interno Neutral
Direcció n Que el producto optimice proyecto
Mendoza Secretaria General
su trabajo
Que el proyecto se
Cristhian
Director de concluya exitosamente Todo el
3 Agreda Director de proyecto Fuerte NO Externo Apoyo
Proyecto Que el producto se proyecto
Mendoza
termine exitosamente.

Que se termine el
proyecto exitosamente.
Equipo de Equipo de Que se desarrolle se Todo el
4 Integrantes del proyecto Fuerte SI Externo Apoyo
proyecto proyecto cumpla con los Proyecto
requerimientos
establecidos.

I. Interesados