ADMINISTRACIÓN ADMINISTRACIÓN DEL PROYECTO 5.1
Introducción En los capítulos anteriores, se ha descrito el conjunto de actividades que se deben llevar a cabo para el éxito del proyecto. Estas actividades han sido desarrolladas en base a un orden establecido metodológicamente que que permit permitirá irán n un adecu adecuado ado seguim seguimien iento to y contr control ol de la gestió gestión n del del proyecto. En el presente capítulo se incluyen los documentos necesarios para una adecuada administración del proyecto, por cuanto será posible identificar y controlar los niveles de avance del desarrollo de las actividades del proyecto. Estos documentos son: el Project Charter , la Estructura de Desglose de Trabajo (Work Breakdown Structure – WBS) y el cronograma de ejecución del proyecto.
5.2Project Charter
Project Charter A. Información General Nombre del Proyecto
Sistema de soporte a la gestión de ventas Para una empresa comercializadora de prendas de vestir
Fecha de Preparación
31/05/2008
Patrocinador:
Tomas Vega Solis – Gerente General
Fecha de Modificación:
31/05/2008
Autorizado por:
Tomas Vega Solís Gerente General
Preparado por: Juan Carlos Dávila – Project Manager Juan Manuel Peña – System Analyst
B.
Prop Propós ósit ito o del del Proy Proyect ecto o (de (descr scrip ipci ción ón de dell pro produc ducto to o ser servi vici cio) o)
El objetivo del presente proyecto es desarrollar un software que permita mejorar la gestión de ventas utilizando como fuente de datos el sistema de punto de venta y control de inventarios de la empresa objeto de estudio.
C. Cump Cumpli lirr
Objetivo de del Pr Proyecto Metas de la Organización con con las las obli obliga gaci cion ones es lega legale les s
que que
Objetivos del Proyecto Desarrollar el Registro de Ventas de acuerdo con
establec establecen en los entes entes gubernam gubernamenta entales les con el
todas todas las especi especific ficaci acion ones es del del ente ente regula regulado dor r
menor costo y tiempo posible. Cumplir con las obligaciones adquiridas con los
(SUNAT) Desarrollar el Informe de Regalías de modo que
proveedores.
cumpla
Cumplir con las obligaciones con los trabajadores
proveedores. Calcular las bonificaciones de ventas tanto a nivel
tratando de optimizar tiempos y costos en este
con
las
especificaciones
de
los
de tiendas como a nivel de vendedor y generar la interface que alimente al sistema de planillas.
proceso. Cump Cumplilirr con con
las las
obli obliga gaci cion ones es
lega legale les s
que que
Cont Contro rola larr de mane manera ra adec adecua uado do la merc mercad ader ería ía
establecen los entes gubernamentales con el
entregada en consignación. Este control implica no sólo el movimiento detallado por artículo sino la
menor costo y tiempo posible Mejorar los procesos internos de la empresa de
facturación automática de consignación. Generar de manera automática los
asientos
contables de ventas. Este asiento contable deberá
modo que se ahorren tiempos y costos.
ser detallado de modo que permita diferenciar las ventas por tipo de pago (contado, con tarjeta) y el Cumplir con los objetivos de ventas y hacer un monitoreo constante del desempeño de la fuerza
tipo de producto. Desarrollar un módulo que permita el ingreso de los presupuestos de ventas (cuotas de ventas) a nivel de vendedor y tienda. De igual manera este módulo
laboral a fin de tomar acciones correctivas en
servirá para hacer un seguimiento al cumplimiento
caso de ser necesario
de las cuotas de ventas comparando lo real versus
Cumplir con todos los requerimientos de los
lo presupuestado. Desarrollar el kardex valorizado de acuerdo a los
entes reguladores del País.
requerimientos
Mejorar la calidad de la información con que
utilizando para ello el método de costeo promedio. Desarrollar una un módulo de alertas que sirva para
cuenta la empresa a fin de mantener la
dar aviso sobre posibles errores en el ingreso de
confiabilidad en los reportes obtenidos. Mejorar la gestión de ventas de modo que se
los datos. Generar informes Gerenciales para un adecuado
pueda
seguimiento de la Gestión de Ventas.
incrementar
la
participación
en
el
del
ente
regulador
(SUNAT)
mercado.
D. Alcance del Proyecto Resultado del Proyecto •
La documentación de la Fundamentación teórica y propuesta de solución del proyecto
•
La documentación del análisis y el modelamiento del negocio y la documentación elaborada para el diseño de la construcción del sistema.
•
La definición y los modelos de los reportes y consultas que serán utilizados por las diferentes áreas de la empresa.
•
Presentación de los prototipos del sistema.
Contenido del Proyecto.
•
Presentación.
•
Resumen.
•
Introducción.
•
Fundamentación teórica.
•
•
•
•
Introducción.
•
Marco Teórico.
•
Objeto de estudio.
•
Campo de acción.
•
Análisis los problemas de la organización.
•
Conclusiones.
Propuesta de solución. •
Introducción.
•
Objetivos del proyecto.
•
Beneficios del proyecto.
•
Conclusiones.
Modelado del negocio. •
Introducción.
•
Modelo de casos de uso del negocio.
•
Reglas del negocio.
•
Realización de los casos de uso del negocio.
•
Modelo de análisis del negocio.
•
Conclusiones.
Requerimientos. •
Introducción.
•
Especificaciones de los requerimientos del sistema.
•
Seguridad del software.
•
Modelo de casos de uso del sistema.
•
Matriz del modelo de negocio y el modelo del sistema.
•
Especificaciones de alto nivel de los casos de uso del sistema.
•
Diagrama del modelo conceptual del sistema.
•
Priorización de los casos de uso.
•
Especificaciones de casos de uso del sistema (casos de uso del núcleo
central).
•
•
Prototipo inicial del sistema.
•
Conclusiones.
Administración del proyecto. •
Introducción.
•
Project charter.
•
Cronograma de ejecución del proyecto.
•
Conclusiones.
•
Conclusiones
•
Glosario de términos
•
Siglario
•
Bibliografía
•
Anexos
Exclusiones •
No se realizará ninguna labor de programación del sistema.
•
Se considera como parte del alcance de este proyecto únicamente a las actividades y procesos que se realizan en las áreas de ventas, Desarrollo del Recursos Humanos, Contabilidad, Control de Inventarios y Control Interno. Todas las demás quedan excluidas del alcance del presente proyecto.
No se considera como parte del proyecto la generación de asientos contables que
•
no sean los referentes a las ventas.
Stakeholders Claves •
Gerente General
– Tomas Vega Solís
•
Gerente de Ventas – Claudio Vienrich
•
Contador General – Marco Sebastiani Chavarri.
•
Jefe del Dpto. de Recursos Humanos
– Mercedes Caballero
Hipótesis o suposiciones •
Los stakeholders de la empresa brindarán todas las facilidades del caso para la
habilitación de los ambientes físicos para el trabajo de los consultores del proyecto. •
Los stakeholders de la empresa brindarán la información necesaria requerida a
solicitud de los consultores con un plazo máximo de 48 horas. •
La Dirección General de la empresa asignará al personal involucrado en el
proyecto en los horarios que sean requeridos (tiempo parcial o total), brindándoles todas las facilidades del caso para su asistencia y/o traslado de un local a otro. •
El liderazgo y la experiencia del Project Manager (PM).
•
La experiencia de los consultores en proyectos similares o del mismo rubro.
Restricciones •
El horario de trabajo de los integrantes del equipo de desarrollo será de Lunes
a Sábado de 8:30 a.m. a 6:30 p.m. •
El proyecto debe terminarse el 10 de Setiembre.
E. Factores Críticos de Éxito del Proyecto Los Indicadores que se medirán para evaluar el éxito del proyecto son los siguientes:
•
•
Cumplimiento de Plazos.
•
Cumplimiento del Cronograma de Actividades.
Calidad de de los Entregables. •
La Calidad de los Entregables (Especificaciones, Documentos y Diagramas), se medirá en términos de Entendimiento, Precisión y Generación de Valor para las siguientes fases del proyecto. Eficiencia de los Procesos.
•
•
Tiempo de Producción de Entregables No Mayor al Planificado.
•
Utilización de Recursos según lo Planificado.
•
Lograr los Objetivos enunciados en el presente Plan del Proyecto.
•
Delimitación precisa del alcance del proyecto.
•
Definición clara de los objetivos del proyecto.
•
Estimación correcta del esfuerzo de todas las actividades del
proyecto.
F.
Planeamiento Inicial del Proyecto al alto nivel
Estimación de recursos requeridos: •
Recursos humanos: •
Un equipo de dos consultores externos.
•
Perú Fashions S.A. designará a los stakeholders y adicionalmente a dos analistas funcionales quienes trabajarán de manera estrechamente coordinada con los consultores externos.
•
Recursos materiales:
Una sala u oficina para el uso exclusivo de los consultores del proyecto.
•
Deberá contar con una mesa de trabajo para 8 personas, pizarra acrílica de 2.20 mts. x 1 mts. Dos (2) computadoras personales Core 2 Duo de 2.2 Ghz , 120 Gb de HD y
•
1 Gb de RAM, con acceso a Internet. •
Una (1) impresora láser.
•
Un (1) proyector multimedia.
•
Un (1) estante archivador con 4 cajones con llave.
•
Gastos asociados de los recursos materiales •
Gastos de Papel
•
Gastos de Impresión
•
Gastos de Electricidad
Costo estimado del Proyecto
PROYECTO
PRESUPUESTO SISTEMA DE SOPORTE A LA GESTION DE VENTAS PARA UNA EMPRESA COMERCIALIAZADORA DE PRENDAS DE VESTIR
GERENTE DE PROYECTO PATROCINADOR
JUAN CARLOS DAVILA TOMAS VEGA SOLIS - GERENTE GENERAL
ULT. MODIFICACION
08/06/2008
Detalles del Presupuesto Gastos Internos Salarios Project Manager System Analyst
Total Gastos Internos Otros Gastos Internos Gastos de Papel Gastos de Impresión Gastos de Electricidad
Total Gastos Internos Gastos Externos Costos de Consultoría Costo del Curso de Titulación
Costo por Hora $25.00 $15.00
#Horas 653.67 697.78
Costo Total $ 16,341.67 $ 10,466.81 $ 26,808.48 Costo Total $ 30.00 $120.00 $ 50.00
$ 200.00 Costo Total $2,500.00
Total Gastos Externos Total Presupuesto
El presupuesto del proyecto no incluye impuesto general a las ventas (IGV) ni el margen de utilidad.
$ 2,500.00 $ 29,508.48
Beneficios Estimados •
Beneficios tangibles. •
Reducir el tiempo y consumo de recursos en la elaboración de informes como:
•
Registro de ventas
•
Informe de regalías
•
Reporte de bonificaciones
•
Beneficios intangibles.
•
Mejorar la gestión de las ventas mediante informes que permitan a la alta gerencia tomar decisiones más adecuadas.
•
Mejorar el desempeño del personal de ventas mediante un manejo mas adecuado de las bonificaciones orientadas a la obtención de objetivos.
•
Conseguir un mejor control del desempeño de las ventas mediante el seguimiento de las cuotas de ventas versus las ventas reales.
Estimación de Fechas a Programar
Fecha de inicio
: 30/04/2008
Fecha de Término
: 10/09/2008
G.
Autoridad del Proyecto
Autorización (Sponsor) Gerente General – Tomas Vega Solís
Gerente del proyecto Juan Carlos Davila
Comité de Proyecto (Dirección) Gerente Comercial – Claudio Vienrich
Contador General – Marco Sebastiani Chavarri Gerente de Proyecto – Juan Carlos Dávila Analista Funcional – Juan Manuel Peña
H. Integrantes del equipo del proyecto, Roles y Responsabilidades Comité del Proyecto: •
Aprobar la visión, alcance y funcionalidad a desarrollar en el proyecto.
•
Evaluar y seleccionar el proveedor con el que desarrollaremos el proyecto.
Sponsor del Proyecto. Responsable de patrocinar el proyecto, incluyendo: •
Definir la visión del proyecto.
•
Obtener el financiamiento del proyecto.
•
Priorizar el proyecto y mantener la prioridad durante la duración del mismo.
•
Apoyar en la obtención de recursos para el proyecto.
•
Apoyar en la resolución de problemas no resueltos en instancias anteriores.
•
Apoyar en la obtención del compromiso requerido de todos los participantes.
Gerente del Proyecto. Responsable del planeamiento, gestión, control del proyecto y de asegurar el éxito del proyecto. •
Definir la visión del proyecto.
•
Obtener el financiamiento del proyecto.
•
Priorizar el proyecto y mantener la prioridad durante la duración del mismo.
•
Apoyar en la obtención de recursos para el proyecto.
•
Apoyar en la resolución de problemas no resueltos en instancias anteriores.
•
Apoyar en la obtención del compromiso requerido de todos los participantes.
•
Integrar la información (cronograma, esfuerzo, etc.) preparada por los participantes del equipo de planificación, tanto para la solicitud de la propuesta como de la definición del proyecto.
•
Elaborar la solicitud de propuesta al proveedor (RFP) y el plan del proyecto.
•
Preparar la matriz de evaluación del proveedor.
•
Canalizar la comunicación entre los proveedores que participan en el proceso de selección y el Banco.
•
Canalizar la comunicación entre el proveedor elegido y el Banco.
•
Comunicar el estado del proyecto, los problemas y riesgos a todo nivel de la organización.
•
Completar los entregables en fecha,
dentro del
presupuesto, con
las
especificaciones requeridas y estándares de calidad. •
Liderar el equipo del proyecto.
•
Gestionar la resolución de problemas, la mitigación de los riesgos y el control de los cambios.
•
Preparar y mantener la documentación del proyecto.
•
Realizar el seguimiento detallado de todo el proyecto.
•
Medir y controlar el presupuesto de horas del proyecto.
•
Dirigir las reuniones de seguimiento del proyecto a nivel de los equipos de trabajo y del comité.
•
Dirigir la reunión de lecciones aprendidas del proyecto y tomar encuestas de evaluación.
•
Realizar reunión de cierre del proyecto.
System Analyst •
Responsable de transmitir las nuevas necesidades identificadas para el proyecto.
•
Apoyar en la preparación de objetivos y alcances.
•
Proporcionar especificaciones funcionales.
•
Proporcionar la lista de actividades funcionales y plazos estimados.
I.
Firmas Nombre/Función
Firma
Fecha
Juan Carlos Dávila – Project Manager
31/05/2008
Juan Manuel Peña – System Analyst
31/05/2008
5.2 WBS (Work Breakdown Structure)
5.3 Cronograma de Ejecución del Proyecto
Hoja de Recursos
Plan de Gestión del Alcance Sistema de Control y Soporte a la toma de decisiones de la Gestión Comercial Preparado por: Juan Carlos Dávila T. Fecha: 30/05/2008 1. Describir cómo será administrado el alcance del Proyecto: Nombre del Proyecto:
Después que el Project Charter y todas sus referencias han sido creadas o modificadas, el project manager preparará, actualizará y validará el documento final del alcance y finalmente lo mostrará al equipo del proyecto para su validación. Un representante del usuario debería siempre aprobar el alcance. Cualquier corrección o modificación pueden ser aplicadas al finalizar esta revisión. El project sponsor puede firmar una aprobación adicional. El alcance aprobado y sus componentes de referencia son congelados. Se realiza el baseline conforme el procedimiento de generación de línea base (baseline) del cronograma. Cualquier cambio debe pasar por un proceso de control de cambios. El Alcance y sus componentes son disponibles para las personas asociadas al proyecto con acceso de SOLO LECTURA.
2.
Evaluar la estabilidad del alcance del proyecto (cómo manejar los cambios, la frecuencia e impacto de los mismos):
Se requiere de un proceso formal de Control de Cambios en los casos que el cambio afecte la línea base del proyecto debido a: •
Retrasos en desarrollo o revisiones del requerimiento.
•
Afinación de estimaciones
•
Cambios en la dirección u objetivos del proyecto.
•
Requerimientos nuevos
•
Cambio de metodología
•
Una vez aprobados, se procederá al procedimiento de regeneración de línea base de ser necesario.
Se debe especificar en el Plan de Proyecto el equipo de control de cambios. El equipo puede estar conformado por el project sponsor, project manager, y otras personas relacionadas con el proyecto. El responsable del equipo es representado por el project sponsor u otra persona que éste asigne.
DESCRIPCIÓN DEL PROCEDIMIENTO 0.1.
ACTIVIDAD 360: CREAR LA SOLICITUD DE CAMBIO
El originador del cambio (persona del equipo que identifica el cambio) lo documentará e ingresará la información requerida en el sistema. En caso no se utilice un sistema automático, debe ingresar la información en el formulario de solicitud de control de cambios. Entre la información requerida se encuentra: •
Nombre del originador
•
Nombre del requerimiento de cambio
•
Fecha de identificación
•
Persona que requiere el cambio: equipo de proyectos, proveedor o usuario
•
Prioridad
•
Fase de administración del proyecto
•
Fase del producto
•
Requerimientos que impacta el cambio
•
Tipo de cambio
•
Descripción del cambio
•
Razón del cambio
•
Equipo de proyecto impactado Administrador/Líder del proyecto Se debe incluir el nombre de todos los documentos que serán modificados en caso de que el cambio sea aprobado (por ejemplo: plan de proyecto, documento de análisis y diseño técnico, etc). Esta información se debe ingresar en el campo Descripción del cambio. Si el cambio es aprobado, los documentos deben ser actualizados para que reflejen estos cambios. Se debe actualizar la sección de Revisiones indicando el cambio realizado asociado con la aprobación del mismo. Los documentos deben ser revisados para asegurarse que los cambios se han implementado correctamente sin necesidad que se realice otra aprobación formal. El project manager debe guardar un listado con todos los cambios que han sido presentados el cual se actualizará conforme el equipo de control de cambios realice la evaluación respectiva.
•
0.2.
ACTIVIDAD 365: REVISAR EL CAMBIO Y HACER LAS RECOMENDACIONES AL EQUIPO DE CONTROL DE CAMBIOS (APROBAR O RECHAZAR)
El requerimiento de cambio es enviado al project manager para su revisión y recomendaciones al equipo de control de cambios. •
El project manager evalúa el cambio, teniendo en cuenta el impacto en el negocio, para el usuario, técnicos o de cronograma.
•
Determina los cambios y estima el esfuerzo que requiere su implementación.
Identifica cualquier cambio en el proyecto si el cambio es aprobado. Si la solicitud es válida, se complementa el análisis y se recomienda una aprobación, caso contrario, se recomienda una desaprobación. Las recomendaciones (aprobado o rechazado) deben ser enviadas al responsable del equipo de control de cambios. Esta recomendación debe indicarse en la solicitud de cambio. •
0.3.
ACTIVIDAD 370: REVISIÓN DE LA SOLICITUD DE CAMBIO
El equipo de control de cambios debe revisar todas las solicitudes de cambios. La actividad principal del responsable del equipo de control de cambios es de revisar todas las solicitudes de cambios, supervisar las reuniones, monitorear y hacer seguimiento a las solicitudes de cambio. En algunos casos, el equipo de control de cambios asignará al project analyst, quien cumplirá el rol de coordinador, teniendo la tarea de crear la agenda de la reunión y almacenar toda la documentación de cada solicitud de cambio. El responsable del equipo de control de cambios podrá invitar a otras personas necesarias a la reunión
de revisión del equipo de control de cambios para que apoyen en la toma de decisiones.
0.4.
ACTIVIDAD 375: TOMAR LA DECISIÓN SOBRE LA SOLICITUD DE CAMBIO
Basado en el análisis anterior, el equipo de control de cambios puede tomar una de estas decisiones: •
Diferir solicitud de cambio: El equipo puede decidir diferir la solicitud de cambio para una nueva fecha o hasta que alguna información adicional sea necesaria entregar a este equipo. Rechazar solicitud de cambio: Si el equipo rechaza la solicitud de cambio, el equipo
•
debe comunicar la decisión y sus razones la originador del cambio. •
Aprobar o Aprobar con modificaciones: Si el requerimiento es aprobado, esta decisión es comunicada automáticamente al originador del requerimiento. Asimismo, el equipo puede realizar modificaciones a la solicitud de cambio antes de la aprobación. El project manager indicará los recursos apropiados para la implementación. Realizar el análisis de impacto detallado: Si el equipo de control de cambios
•
encuentra que es necesario realizar un análisis adicional, puede requerir que se complete la información de análisis de impacto detallado o a nivel general. Esta información es la siguiente: Impacto en el presupuesto. Impacto en el cronograma. Impacto en recursos. Impacto en otros equipos o aplicaciones. Impacto en el tamaño del proyecto. Impacto en arquitectura. • Supuestos, riesgos y dependencias. Se debe incluir la documentación adicional necesaria para este análisis. El responsable del equipo de control de cambios debe indicar el resultado de la evaluación en la solicitud de cambio. • • • • •
•
0.5.
ACTIVIDAD 380: ¿LA SOLICITUD ES DIFERIDA O ESTÁ PENDIENTE?
En caso la solicitud se encuentre diferida o pendiente, continuar con la actividad 385. Caso contrario con la actividad 390.
0.6.
ACTIVIDAD 390: ¿LA SOLICITUD ES APROBADA?
Si la solicitud es aprobada, continuar con la actividad 395, caso contrario con la actividad 400.
0.7.
ACTIVIDAD 385: NOTIFICAR AL PM Y AL ORIGINADOR
La solicitud diferida, con las razones respectivas, son retornadas al projct manager e incluye las instrucciones para que sea reactivada. El responsable del equipo comunica esta decisión al originador de la solicitud de cambio.
3.
¿Cómo los cambios al alcance, serán identificados y clasificados?
Los cambios de alcance serán identificados de acuerdo al procedimiento de la respuesta anterior. Los niveles de aprobación de los cambios de alcance se darán en función de la categorización del proyecto (basada en el tamaño del proyecto)
Tamaño Pequeño Mediano
Número de horas
Nivel de autorización
1 a 25 Hrs 26 a 100 Hrs
Project Manager Project Manager
Grande Muy Grande 4.
101 a 500 Hrs 501 a mas Hrs
Sponsor Gerente General
Describir cómo los cambios del alcance serán integrados al proyecto: ACTIVIDAD 395: ACTUALIZAR LOS CAMBIOS / REBASELINE
El equipo de implementación (a cargo de un analista responsable) completará las actividades que han sido asignadas por el equipo de control de cambios. El equipo de implementación realizará la implementación respectiva y entregará la documentación completa necesaria al equipo de control de cambios. Si los cambios a realizarse impactan en el cronograma por más de 1 semana, se deberá realizar un rebaseline a éste.
ACTIVIDAD 400: CAMBIAR EL ESTADO A LA SOLICITUD Una vez entregada esta información, el equipo de control de cambios cambiará el estado a la solicitud y adicionará la documentación relacionada. (DIFERIDA, COMPLETADA, RECHAZADA)
ACTIVIDAD 405: NOTIFICAR EL CIERRE DE LA SOLICITUD El responsable del equipo realizará lo siguiente: •
Notificará al equipo.
•
Notificará al originador del cambio.
5.
Comentarios adicionales:
Anexo 1: Formulario de solicitud de control de cambios
Formulario de solicitud de cambio Número de solicitud de cambio: (Será asignado por el Project Manager)
Fecha de solicitud:
Nombre de solicitud de cambio: (máximo 10 palabras) Originador:
Dirección electrónica del Originador:
Nombre del proyecto: Prioridad del cambio: (Seleccionar Baja / Media / Alta) Fase del proyecto: (Inicio, Planificación, Ejecución,
Project Manager:
Control, Cierre)
Responsable del Equipo de Control de Cambios:
Fase del producto: (Ingrese la fase de desarrollo del producto; análisis funcional, análisis técnico, construcción, pruebas, implementación, capacitación) Tipo de cambio: (hardware, software, documentación, requerimiento, alcance, cronograma, capacitación, etc)
Descripción del cambio: Adicione una breve descripción del cambio solicitado. Esta debe incluir cualquier cambio en recursos, entregables, tiempos y presupuesto.
Razón del cambio: Liste las razones del cambio (circunstancias externas, error / omisión en el alcance o funcionalidad requerida, adición de valor, etc)
Motivos de negocio:
Motivos del sistema:
Liste los motivos del negocio por lo cual es necesario este cambio (por ejemplo: recientes cambios en políticas internas, etc)
Liste los motivos del sistema por lo cual es necesario este cambio (por ejemplo: mejora en el rendimiento del sistema, falta de apoyo del proveedor, etc)
Impacto en el negocio:
Impacto en el proyecto:
Describe el impacto en el negocio si es que el cambio es implementado (por ejemplo: recursos adicionales. disminución de la eficiencia del proceso, cambios en
Describe el impacto en el alcance y/o cronograma si el cambio es implementado (por ejemplo:tiempo de integración, requerimiento de nuevos procesos,
la estructura organizativa, etc)
modificación de fecha comprometida, etc)
Beneficios del cambio:
Impacto en costos:
Describe los beneficios financieros y no financieros relacionados con la implementación de este cambio (por ejemplo; reducción en los costos por transacción, mejorar performance, aumentar la satisfacción del cliente, etc)
Describe los costos financieros o no financieros asociados con la implementación de este cambio (por ejemplo: ampliación de presupuesto, reducción temporal del rendiemiento delpersonal, etc)
Equipos de proyecto impactados: •
Liste todos los equipos de proyecto impactados por este cambio, incluyendo al líder del equipo.
Documentación de soporte: Incluir cualquier documentación que pueda sustentar el cambio solicitado.
Resultado de la evaluación del Project Manager ___ Aprobado ___ Rechazado
Resultado de la evaluación del Equipo de Control de Cambios ___ Diferido ___ Rechazado ___ Aprobado ___ Aprobado con modificaciones ___ Realizar análisis de impacto detallado
Anexo 2: Listado de solicitudes de cambio Nro
Aplicativ o
Cambio
Fecha de solicitud
Originador
Asignado a
Fecha de rpta
Estado
5.4Conclusiones
La Administración del Proyecto es una actividad muy importante que debe ser llevada a cabo por el Gerente del Proyecto (PM), el cual
tiene un alto grado de
responsabilidad en el éxito del mismo. Debe apoyarse en un equipo humano que se encuentre totalmente comprometido en llevar a cabo el planeamiento, gestión y ejecución de todas las actividades identificadas en el proyecto. También deben utilizar herramientas de planificación y control automatizadas que permitan realizar un adecuado seguimiento del cumplimiento de todas las actividades y que les permita identificar problemas que se manifiestan como retrasos o metas no cumplidas dentro del cronograma del proyecto. En este capítulo hemos descrito las herramientas que el Gerente del Proyecto (PM) y su equipo de trabajo utilizarán para una eficiente administración de la gestión de este proyecto. Las actividades y tiempos estimados están en función a los alcances de este proyecto y las limitaciones de tiempo que se originan por los plazos de entrega de la documentación requerida.
Solución
