Proyecto Final

Gestión del Proyecto
https://cid-251168439c8f78a4.skydrive.live.com/self.aspx/EE%7C_GEP/EE%7C_GEP%20EQ9/Proyecto/GEP2009%7C_EQ9%7C_T11%7C_PlaneacionDelProyecto.mpp

Producto final
https://cid-251168439c8f78a4.skydrive.live.com/browse.aspx/EE%7C_GEP/EE%7C_GEP%20EQ9/Proyecto

Tarea 14

Informe Final

View more documents from Lia Nakid.

Tarea 14

Control del programa

Comparación de tiempo programado y real

Duración de las actividades y holgura

Uso de los recursos

Tarea 13

Ejecución del proyecto

24. ¿Realicé la construcción de un equipo de trabajo eficaz?
El equipo de trabajo es pequeño y la posición jerárquica de los dos miembros se encuentra en el mismo nivel, por ello no hay una persona encargada de construir el equipo de trabajo. Sin embargo, el equipo de trabajo sí es eficaz.

25. ¿Qué debo hacer para saber dónde estoy en el programa, estimación, y el presupuesto?
Se lleva a cabo un control del programa, tiempo y presupuesto mediante la herramienta software Microsoft Proyect, dónde se realizan comparaciones de los sucesos reales con el plan de línea base, establecido al comienzo del proyecto.

26. ¿Estoy llevando a cabo la gestión de los riesgos?
Si, se cuenta con un plan de mitigación ante la aparición de riesgos, y se plantean nuevos riesgos durante las reuniones del equipo de trabajo. Sin embargo, no se han identificado nuevos riesgos, y los anteriormente establecidos se encuentran bajo control.

27. ¿Estoy preparado para programar la solución de problema?
Si, el equipo se encuentra preparado para solucionar los problemas que se presenten, ya que se tiene una lista de identificación de ciertos riesgos con sus respectivos planes de mitigación, así como con una serie de medidas preventivas para evitar la aparición de éstos. En caso de que el problema sea inesperado, el equipo tiene la flexibilidad de programar reuniones extemporáneas y establecer la solución más adecuada.

28. ¿He gestionado la solicitud de cambios de alcance?
No se ha presentado la situación de realizar un cambio de alcance.

29. ¿He gestionado la calidad?
Si, se utilizan herramientas para gestionar la calidad de las presentaciones y traducciones, tanto en el contenido como en el diseño. Las herramientas son listas de verificación con estándares establecidos, en dónde se verifica que los productos cumplan dichos estándares.

30. ¿He realizado micromanagement cuando sea necesario y no en otra parte?
No ha sido necesario aplicar una acción de micromanagement.

31. ¿Mi subcontratista cumple sus compromisos?
El proyecto no tiene la naturaleza necesaria para subcontratar empresas que realicen actividades, por lo tanto no aplica.

32. ¿Entiendo expectativas del cliente, y me entiendo con ellos?
Si, se entiende la expectativa del cliente y se realizan reuniones de avance dónde se muestran los productos realizados, para asegurar la completa satisfacción del cliente y aplicar las acciones correctivas cuando sea necesario.

33. ¿Estoy realizando con regularidad la reunión del equipo, y son eficaces?
Si, los miembros del equipo mantienen reuniones semanales informales, donde se tratan los puntos importantes del proyecto como los posibles riesgos, las soluciones, ciertas medidas preventivas y la evaluación de los productos desarrollados.

34. ¿Qué debo hacer para informar el estado del proyecto y las cuestiones pendientes con regularidad?
Es necesario realizar reuniones de equipo, debido a que los miembros cuentan con la flexibilidad necesaria para ello y se evitan retrasos que surgen en la comunicación por algún otro medio. Para mantener el control de las actividades pendientes, se realizan revisiones de avance sobre el plan de línea base y se realiza una lista de actividades pendientes.

35. ¿Estoy teniendo el momento de reflexionar sobre los progresos en privado?
Si, cada miembro del equipo tiene la obligación de darse un tiempo para analizar los avances del proyecto e identificar fallos, problemas, riesgos u otros aspectos. No se encuentran establecidos como actividades, sin embargo es una práctica que se realiza días antes de la reunión de avance.

36. ¿Qué debo hacer para mi equipo y celebrar los éxitos?
Es necesario contar con actividades de recreación y celebración de éxitos, lo cual ayuda a despejar el panorama y a continuar el proyecto desde otra perspectiva.

Tarea 13

Gep2009 Eq9 T13 Pre Hallows EjecucióN Del Proyecto

View more OpenOffice presentations from Lia Nakid.

Tarea 12

Introducción

Una vez que finaliza la etapa de planeación del proyecto, donde se establece un plan preliminar de las actividades a realizar, los recursos, los costos y los tiempos estimados, la siguiente etapa que hay que llevar a cabo es una programación de referencia con todas las actividades desglosadas y especificadas a detalle. Esta programación debe considerar productos a entregar, responsables de la actividad, recursos y una serie de detalles que deben ser tomados en cuenta para la realización satisfactoria del proyecto.

La siguiente es una reseña del libro David y Goliat. Programación de referencia del proyecto, donde el autor nos ejemplifica mediante una novela, el conjunto de consideraciones que hay que tomar en la programación del proyecto, así como las herramientas que se recomienda utilizar y las posibles reacciones de los miembros del equipo, clientes, subcontratistas y personal involucrado.

Reseña

Díaz Martín, Ángel. (2007). David y Goliat, Programación de Referencia del Proyecto. México: Alfaomega Grupo Editor.

En su cuarta y obra, Díaz Marín continua la historia de David, un director de proyectos de una empresa contratista que se encuentra con una oportunidad única en su carrera, que es llevar la dirección del proyecto más grande e importante de la compañía. Sin embargo, David era el director de proyecto del Alfa, un proyecto mediano que también se está llevando a cabo en la empresa y que fue transferido en el segundo tomo del libro a Ignacio, el cual comenzó sus nuevas funciones como director y fue presentado al cliente. No obstante, al ser David el antiguo director, es frecuentemente cuestionado y se le pide la opinión acerca de diversas situaciones que se van presentando en el proyecto, sin ser él el encargado de realizar este trabajo, por lo que a veces se encuentra con situaciones de falta de tiempo o de presión laboral.

Aunque en el libro anterior, David y Goliat. Planificación preliminar del proyecto, el proyecto Alfa había cambiado de Director y se encontraba bajo control, en éste libro el autor nos narra como un proyecto puede fracasar debido a cierto fallos que causan un gran impacto en los tres aspectos que definen al proyecto: costos, alcance y programa.

En la programación del proyecto Goliat, David tiene que llevar a cabo la administración del equipo de trabajo y dar opiniones con respecto a los entregables de cada uno de ellos. En este libro, continúan participando los mismos personajes que en los libros anteriores, y podemos observar como cada personaje va evolucionando conforme el proyecto avanza, y sus actividades y responsabilidades van cambiando proporcionalmente con su progreso.

Como en los libros anteriores, no solamente el autor nos muestra una serie de herramientas para gestión de proyectos, sino también aspectos del comportamiento humano que pueden ser determinantes en el desarrollo de éstos. Nos ejemplifica las posibles reacciones de ciertos miembros del equipo y aspectos positivos y negativos de la personalidad de cada uno de ellos que pueden tener un impacto en el proyecto.

Desde otra perspectiva, el autor pretende simular las posibles situaciones que se pueden presentar en la gestión de proyecto, desde un entorno cualitativo y cuantitativo. Se dan a conocer ciertas responsabilidades y las actitudes que toman los personajes, identificando cuáles de éstas son las adecuadas de acuerdo a su puesto y jerarquía, y cuáles no los son. Por otra parte, se introducen una serie de herramientas de gestión de proyectos, aplicables en cada fase del ciclo de vida de éste, y se proponen nuevas herramientas que pueden ser utilizadas para llevar un control más estricto de las variables del proyecto, que nos encaminen a la realización exitosa de éste.

Tarea 11

1º Informe De Avance

View more Microsoft Word documents from Lia Nakid.

Tarea 11

Planeación del Proyecto

10. ¿He definido los riesgos y desarrollar planes para mitigarlos?

Riesgos
· Las actividades requieren mucho tiempo, lo cual puede retrasar las entregas de avances.
· Aparición de nuevos requerimientos que no fueron identificados por el cliente al comienzo del proyecto.
· Retrasos en los avances que causen cuellos de botella en las actividades.
· Fallos en el recurso tecnológico utilizado para el desarrollo del proyecto.

Mitigación
· Se tendrán días de trabajo exhaustivo para realizar las actividades pendientes o retrasadas y continuar el proyecto sin complicaciones.
· Se llevarán los recursos a un centro especializado para su reparación, sin embargo se respaldarán todos los avances del proyecto en 3 medios diferentes para evitar pérdida de información.
· Se cuenta con recursos tecnológicos de apoyo.

Medidas preventivas
· Planeación minuciosa de los tiempos de realización de las actividades y los recursos con los que se cuenta.
· Mantener una constante comunicación con el cliente para asegurar que los requerimientos se cumplen de manera apropiada.
· Programar reuniones con el cliente para involucrarlo en el proceso y mantenerlo informado del progreso.
· Definir los actividades que realizará cada miembro del equipo, verificando desde el comienzo del proyecto que no falten requerimientos.

11. ¿He documentado el proyecto de supuestos y limitaciones?

Si, se encuentran documentados en el Anteproyecto.
Alcances
I. Traducción completa del texto del libro.
II. El libro incluirá todas las figuras, casos, plantillas y ejemplos.
III. Creación de presentaciones de power point estandarizadas por capítulos.
IV. Definición de estructura y diseño de todas las presentaciones.

Limitaciones
I. No se traducirán las figuras, diagramas y plantillas.
II. La traducción del libro no será publicada.
III. El material solamente abarcará la información incluida en el libro Enterprise Integration. The Essential Guide to Integration Solutions (Boston, 2005). Gold-Bernstein, Beth y Ruh, William. Addison-Wesley.

12. ¿He desarrollado un plan de calidad?

Si, se han creado 3 métricas de evaluación de la calidad. Cada producto será sometido evaluación antes de la reunión de avance con el cliente. Las métricas utilizadas serán:
v Lista de Verificación de Características.
v Evaluación de la Calidad del Contenido.
v Evaluación Alcance/Tiempo.

13. ¿He elaborado una lista detallada de las actividades del proyecto?
Si. Ver Anexo 1

14. ¿He definido las dependencias entre las actividades?
Si. Ver Anexo 1.

15. ¿He construido un proyecto de estimación de la labor necesaria?
Si. Ver Anexo 1.

16. ¿Me han asignado recursos y nivelado ellos?
Si. Ver Anexo 1.

17. ¿He completado el programa, con los hitos?
Si. Ver Anexo 1.

18. ¿He alineado el calendario con las necesidades del cliente?
Si. Las restricciones del cliente son mínimas y se han programado las actividades de acuerdo a éstas.

19. ¿He elaborado un proyecto de presupuesto?
Costos estimados

Análisis de Requerimientos
Transporte: $12 x 2 = $24 por 10 visitas = $240
Entrevistas y Documentación: papelería $100
Costo horas-hombre: $ 50 x 5hrs = $250 por 2 personas = $500
Total: $840

Revisión de avances
Transporte: $12 x 2 = $24 por 10 visitas = $240
Total: $240

Diseño
Costo horas-hombre 50 x 5hrs = $250
Energía eléctrica: $100
Total: $350

Desarrollo
Costo horas-hombre 50 x 100hrs = $5000
Energía eléctrica: $100
Total: $5100

Reporte
Papelería= $400
Total: $400
Costo total aproximado del proyecto= $6930

20. ¿He previsto la aplicación?
Si. El proyecto no cuenta con aplicación en empresa alguna.

21. ¿He previsto la realización?
Si. Se han planeado cuidadosamente los tiempos, las actividades y los recursos.

22. ¿He previsto para las comunicaciones?
Si. La comunicación formal establecida es directa, mediante reuniones del equipo de trabajo y vía correo electrónico.

23. ¿He preparado un plan de proyecto?
Si. Ver anexo 1.


Anexo 1

Archivo de Microsoft Proyect:

https://cid-251168439c8f78a4.skydrive.live.com/self.aspx/EE%7C_GEP/EE%7C_GEP%20EQ9/Proyecto/GEP2009%7C_EQ9%7C_T11%7C_PlaneacionDelProyecto.mpp

Tarea 11

Herramientas De PlaneacióN

View more presentations from Lia Nakid.

Tarea 10

Gep2009 Eq9 T10 Pre Software Librede GestióNde Proyectos

View more presentations from Lia Nakid.

Lectura 16

Gep2009 Lec16 Eq9 Pre Gido&Clements Cap.11 Control Del Programa

View more presentations from Lia Nakid.

Tarea 8

Introducción

Al comenzar un proyecto, se realizan estructuras preliminares, se forman los equipos de trabajo y se asignan actividades preliminares, sin embargo en la etapa de planeación de proyectos, es necesario definir todos los participantes, recursos y tiempos que serán los factores que definirán el éxito del proyecto en el futuro.

En esta etapa se deben definir de manera precisa las actividades de cada miembro del equipo, así como todos los recursos que utilizarán, los documentos que entregarán con los avances del proyecto y las fechas tanto de entrega, como de reuniones que se lleven a cabo con el equipo del proyecto o con el cliente.

Para realizar esta planeación es necesaria la utilización de una serie de herramientas de apoyo a la planeación, y documentos o reportes estándar necesarios para que la totalidad del equipo tenga conocimiento del estado del proyecto y se entreguen los avances al cliente.

En la siguiente reseña del libro de Ángel Díaz Martín, David y Goliat. Planificación Preliminar del Proyecto (México, 2007) el autor se enfoca en la fase de planeación de un proyecto, continuando con la novela relatada en la primera parte “David y Goliat. Las Tribulaciones de un Director de Proyectos” y “David y Goliat. Iniciación del Proyecto” para ejemplificar el inicio de un proyecto, donde participan activamente las dos empresas involucradas, cada una con diferentes participantes para cubrir determinados puestos y actividades, así como los factores que se deben considerar al comenzar un proyecto, los puntos críticos que se deben solucionar primeramente y las relaciones jerárquicas entre los miembros del equipo del proyecto. Todo esto es narrado desde la perspectiva de un Director de Proyectos, que no solamente tiene que lidiar con la problemática de la planeación del nuevo proyecto, que es además el más importante para la empresa, sino también con su salida como Director del proyecto en el que se encontraba, y el balance que le tiene que dar al trabajo con su vida familiar y a las oportunidades personales que se presentan.

Reseña

Díaz Martín, Ángel. (2007). David y Goliat, Planificación Preliminar del Proyecto. México: Alfaomega Grupo Editor.

En su tercera obra, Díaz Marín continua la historia de David, un director de proyectos de una empresa contratista que se encuentra con una oportunidad única en su carrera, que es llevar la dirección del proyecto más grande e importante de la compañía. Sin embargo, David era el director de proyecto del Alfa, un proyecto mediano que también se está llevando a cabo en la empresa y que fue transferido en el segundo tomo del libro a Ignacio, el cual comenzó sus nuevas funciones como director y fue presentado al cliente. No obstante, al ser David el antiguo director, es frecuentemente cuestionado y se le pide la opinión acerca de diversas situaciones que se van presentando en el proyecto, sin ser él el encargado de realizar este trabajo, por lo que a veces se encuentra con situaciones de falta de tiempo o de presión laboral.

El relato, tiene comienzo después de la reunión de iniciación del proyecto, cuando se empiezan a llevar a cabo las actividades de planeación. Al ser el Director del Proyecto, David se reúne con el Director de proyectos de la empresa cliente, Claudio, con el cual se ha entendido de buena manera y en las reuniones se presentan concreta y precisamente los aspectos necesarios para la planificación.

Al inicio de la planificación, a David se le presenta la oportunidad de realizar un viaje de placer con su familia por una semana, el cual fue ganado en una rifa. En este momento David tiene que tomar la decisión de dejar el proyecto durante 1 semana en su etapa preliminar, ya que su esposa ha sido insistente en su interés de ir y le recuerda lo que él siempre menciona acerca de los proyectos: “Nadie es indispensable”.

David lidiaba con los problemas que presentaba el proyecto, así como con la planeación de su viaje al Caribe y la sincronización de éste con otro viaje que tendría que hacer a Nueva York para tener un recorrido por las instalaciones de una empresa de la misma índole que la del proyecto Goliat. Mientras esto sucedía, vemos como algunos miembros del equipo muestran su apoyo en cuanto a las tareas del proyecto y el mismo Claudio le facilita las cosas para que David pueda realizar este viaje.

Aquí el autor plantea la idea de que es necesario equilibrar nuestra vida familiar con el trabajo, pues al tomar un descanso y des estresarnos de la vida laboral, comenzamos de nuevo con más energías y podemos realizar un mejor trabajo.

Desde otra perspectiva, el autor enfatiza de nuevo las características de los diferentes grados jerárquicos de la organización, de los miembros del equipo de proyecto, y se enfoca en las relaciones entre los dos equipos de proyecto, el del contratista y el del cliente. Se dan a conocer ciertas responsabilidades y las actitudes que toman los personajes, identificando cuáles de éstas son las adecuadas de acuerdo a su puesto y jerarquía, y cuáles no los son. Como en el caso de Paloma, encargada de la programación, la cual trabaja de manera eficiente y eficaz, sin embargo en ocasiones delega el trabajo hacia arriba, lo que significa que pone en apuros a David para que tome decisiones con respecto a algunos problemas o reportes. O en el caso de Ignacio, que aunque es el nuevo director del proyecto Alfa, frecuentemente pide la opinión de David, el cual ya no forma parte de este proyecto y tiene una elevada carga de trabajo con sus propias actividades.

Finalmente, es importante recalcar que cada personaje cuenta con una función muy específica, pues nos muestra los perfiles y habilidades que deben tener los miembros del equipo del proyecto dependiendo del puesto que ocupen y las actitudes que es recomendable evitar; de la misma forma se presentan ciertas actitudes tomadas por las personas ante diferentes circunstancias y posibles formas de abordarlas para contrarrestar el efecto. Con esto podernos concluir que el reto más grande y la causa principal de los riesgos en un proyecto, son las relaciones humanas.

Tarea 9

Comprensión del Proyecto

1. ¿Entiendo la justificación del proyecto?

La traducción del libro Enterprise Integration y la elaboración de material para las presentaciones de cada capítulo, tienen la finalidad de solucionar la problemática presentada, así como de estandarizar el material utilizado durante el curso, asegurando la calidad del mismo para facilitar la comprensión por parte del alumno.

La finalidad de realizar una traducción, es evitar que el alumno pierda tiempo valioso en traducir el material, el cual puede ser utilizado para el estudio de la materia y desarrollo de proyectos, así como asegurar que la información sea la misma y se encuentre bien estructurada.
Por su parte, las presentaciones creadas en Microsoft Power Point para cada uno de los capítulos, asegurará que se encuentre en éstas toda la información relevante, diagramas, figuras, plantillas y casos presentados en la bibliografía.
Lo que se desea con la realización de este material didáctico y la traducción del libro, es la estandarización de la información para la experiencia educativa Sistemas Integrales en las Organizaciones, para que no existan discrepancias y se mantenga un cierto nivel de calidad en las presentaciones.

2. ¿Qué debo hacer para comprender los antecedentes del proyecto?

En la experiencia educativa Sistemas Integrales en las Organizaciones, no se cuenta con una bibliografía completa y didáctica en español, que se pueda tomar como fuente principal de consulta durante el curso. La bibliografía ideal que engloba la mayor parte de los conceptos necesarios a tratar en la experiencia educativa, es Enterprise Integration. The Essential Guide to Integration Solutions (Boston, 2005). Gold-Bernstein, Beth y Ruh, William. Addison-Wesley, sin embargo se encuentra únicamente en ingles. Se observó que los alumnos no cuentan con el dominio total del idioma, por lo cual hay diversidad de términos utilizados para un mismo tema, diferentes traducciones del texto e incluso, algunas veces se presentan textos sin coherencia o ilógicos.

Otro problema presentado es la falta de estandarización en el material de apoyo a las presentaciones, las cuales son diseñadas de manera diferente y en las que la información no es suficiente.

Estas problemáticas causan al alumno mayor dificultad en el entendimiento de la materia, así como la utilización de la mayor parte del tiempo en la realización del material, y no en el estudio de éste.

3. ¿Entiendo las políticas del proyecto?

• Traducción completa del texto del libro.
• El libro incluirá todas las figuras, casos, plantillas y ejemplos.
• Creación de presentaciones de power point estandarizadas por capítulos.
• Definición de estructura y diseño de todas las presentaciones.
• No se traducirán las figuras, diagramas y plantillas.
• La traducción del libro no será publicada.
• El material solamente abarcará la información incluida en el libro Enterprise Integration. The Essential Guide to Integration Solutions (Boston, 2005). Gold-Bernstein, Beth y Ruh, William. Addison-Wesley.

4. ¿Entiendo cuales son los jugadores y las funciones que tendrá?

Equipo del proyecto:

Lia Nakid Cordero
Actividades: Traducción del libro Enterprise Integration.
Verificación la calidad de las presentaciones realizadas para cada capítulo.
Responsabilidades: 1 computadora portátiles y 1 dispositivo USB. Traducción del texto del libro. Supervisión de las presentaciones.

Aralis Pegueros García
Actividades: Corrección de las presentaciones realizadas para cada capítulo.
Verificación la calidad de las traducciones de cada capítulo.
Responsabilidades: 1 computadora de escritorio y 1 dispositivo USB. Elaboración de las presentaciones. Supervisión de la traducción.

Cliente:

Dr. Carlos Arturo Torres Gastelú

5. ¿Entiendo las prioridades del cliente?

El cliente, catedrático de la experiencia educativa Sistemas Integrales en las Organizaciones, identificó discrepancias en la traducción del material didáctico, así como presentaciones incompletas y no estandarizadas en relación a la bibliografía principal de la experiencia educativa, la cual es Enterprise Integration. The Essential Guide to Integration Solutions (Boston, 2005). Gold-Bernstein, Beth y Ruh, William. Addison-Wesley.

Definición del Proyecto

6. ¿He definido el proyecto?

La solución propuesta al problema anterior, es la elaboración del material didáctico para ésta experiencia educativa. Por Material didáctico se refiere a la traducción completa de la bibliografía Enterprise Integration. The Essential Guide to Integration Solutions (Boston, 2005). Gold-Bernstein, Beth y Ruh, William. Addison-Wesley, incluyendo todos los casos de estudio, ejemplos, figuras y plantillas expuestas por el autor. Cada capítulo se presentará en formato PDF, junto con una presentación en Microsoft Power Point, que cumpla ciertos estándares de calidad y diseño y cuente con la información más relevante completa y presentada claramente.

7. ¿He establecido el ámbito de aplicación de sistemas y proyectos?

Su enfoque es la elaboración de material didáctico completo y estandarizado para la experiencia educativa Sistemas Integrales en las Organizaciones.

8. ¿Han determinado la manera en que los resultados serán revisados y aprobados?

Entregables por etapas del proyecto.
Planeación: cronograma de actividades, descripción de restricciones
Desarrollo: Capítulos en formato PDF con su respectiva presentación en formato PPT.
Entrega: Traducción total del libro y por capítulos en formato PDF y presentación en formato PPT de cada capítulo.

9. ¿He definido la estructura y organización del equipo de cliente?

Si.

Lectura 10

Gep2009 Eq9 Lec10 Pre Gabriel Baca Uribe Parte4 Estudio Economico

View more presentations from Lia Nakid.

Tarea 7

Solicitud de Propuesta

Solicitud de propuesta del proyecto de “Elaboración de material didáctico para la Experiencia Educativa Sistemas Integrales en las organizaciones, donde se especifica la información detallada de la forma de realización del proyecto, los requerimientos, las formas de entregar y documentar avances y demás.

Nombre del proyecto
Elaboración de material didáctico para la Experiencia Educativa Sistemas Integrales en las Organizaciones.

Empresa cliente
Universidad Veracruzana
Dr. Carlos Arturo Torres Gastelú

I. SECCIÓN TÉCNICA

1. ANTECEDENTES DEL PROYECTO

a) DEFINICIÓN DEL PROBLEMA

En la experiencia educativa Sistemas Integrales en las Organizaciones, no se cuenta con una bibliografía completa y didáctica en español, que se pueda tomar como fuente principal de consulta durante el curso. La bibliografía ideal que engloba la mayor parte de los conceptos necesarios a tratar en la experiencia educativa, es Enterprise Integration. The Essential Guide to Integration Solutions (Boston, 2005). Gold-Bernstein, Beth y Ruh, William. Addison-Wesley, sin embargo se encuentra únicamente en ingles. Se observó que los alumnos no cuentan con el dominio total del idioma, por lo cual hay diversidad de términos utilizados para un mismo tema, diferentes traducciones del texto e incluso, algunas veces se presentan textos sin coherencia o ilógicos.
Otro problema presentado es la falta de estandarización en el material de apoyo a las presentaciones, las cuales son diseñadas de manera diferente y en las que la información no es suficiente.
Estas problemáticas causan al alumno mayor dificultad en el entendimiento de la materia, así como la utilización de la mayor parte del tiempo en la realización del material, y no en el estudio de éste.

b) PROPUESTA DE SOLUCIÓN

La solución propuesta al problema anterior, es la elaboración del material didáctico para ésta experiencia educativa. Por Material didáctico se refiere a la traducción completa de la bibliografía Enterprise Integration. The Essential Guide to Integration Solutions (Boston, 2005). Gold-Bernstein, Beth y Ruh, William. Addison-Wesley, incluyendo todos los casos de estudio, ejemplos, figuras y plantillas expuestas por el autor. Cada capítulo se presentará en formato PDF. También se verificarán las presentaciones en Microsoft Power Point. Esto consiste en asegurar que cumplan ciertos estándares de calidad y diseño y cuenten con la información más relevante completa y presentada claramente.

c) JUSTIFICACIÓN

La traducción del libro Enterprise Integration y la verificación de las presentaciones de cada capítulo, tienen la finalidad de solucionar la problemática presentada, así como de estandarizar el material utilizado durante el curso, asegurando la calidad del mismo para facilitar la comprensión por parte del alumno.
La finalidad de realizar una traducción, es evitar que el alumno pierda tiempo valioso en traducir el material, el cual puede ser utilizado para el estudio de la materia y desarrollo de proyectos, así como asegurar que la información sea la misma y se encuentre bien estructurada.
Por su parte, la verificación y evaluación de las presentaciones de cada uno de los capítulos, asegurará que se encuentre en éstas toda la información relevante, diagramas, figuras, plantillas y casos presentados en la bibliografía.
Lo que se desea con la realización de este material didáctico y la traducción del libro, es la estandarización de la información para la experiencia educativa Sistemas Integrales en las Organizaciones, para que no existan discrepancias y se mantenga un cierto nivel de calidad en las presentaciones.

2. OBJETIVOS

Objetivo general

Elaborar el material didáctico de la experiencia educativa Sistemas Integrales en las Organizaciones, para asegurar la veracidad de las traducciones y la completa estructuración de las presentaciones, estandarizando el diseño, la información y estructura; y también cubriendo ciertos requisitos de calidad.

Objetivos específicos

• v Traducir el libro Enterprise Integration (Boston, 2007) Gold-Berstein & Ruh.
• v Verificar que las presentaciones en Microsoft Power Point estén completas y con información veraz.
• v Definir la estructura y diseño de las traducciones.
• v Especificar los requisitos de calidad del material didáctico.

II. SECCIÓN ADMINISTRATIVA

1. PRODUCTOS A ENTREGAR

a) INFORMACIÓN ESPECÍFICA

El producto final consiste en una traducción completa del texto del libro Gold-Bernstein & Ruh (2005). Enterprise Integration. The Essential Guide to Integration Solutions (Boston: Addison-Wesley) entregado de forma completa y por capítulos, en formato PDF junto con un reporte de evaluación de las presentaciones en formato PPT de Microsoft Power Point de cada uno de los capítulos, contando con una estructura y diseño estandarizados.
La especificación de cada producto se encuentra en el Anexo 1.

b) CANTIDAD, FORMATO Y DESCRIPCIÓN

La cantidad de productos son la traducción de los 13 capítulos del libro Enterprise Integration entregados en un solo archivo y por capítulos, en formato PDF. Los productos deberán presentar las características especificadas en el Anexo 1.

c) MÉTRICAS DE EVALUACIÓN DE LA CALIDAD

Cada producto será sometido evaluación antes de la reunión de avance con el cliente. Las métricas utilizadas serán:

v Lista de Verificación de Características.
v Evaluación de la Calidad del Contenido.
v Evaluación Alcance/Tiempo.

Las características de cada una de las métricas se encuentran especificadas en el Anexo 2 del presente documento.

2. DESCRIPCIÓN DE TAREAS DE TRABAJO

Las tareas serán divididas entre los miembros del equipo, y cada uno de éstos contará con actividades específicas que deberá cumplir en un período de tiempo determinado, así como un conjunto de entregables, resultado de las actividades.
Cada actividad será realizada en el momento y lugar que la persona considere adecuado, mientras la actividad concluya en la fecha especificada y se genere un producto tangible en el tiempo permitido.
La descripción de las tareas de cada miembro y los entregables de cada actividad se encuentran especificados en el Anexo 3.

3. PROGRAMA DEL PROYECTO

A. CRONOGRAMA DE ACTIVIDADES

En el Anexo 4 se encuentra la gráfica de GANTT donde se establecen las actividades a realizar y las fechas, así como las reuniones internas y de avance del proyecto.

B. REUNIONES INTERNAS

Las reuniones internas se llevarán a cabo en las instalaciones de la Universidad Veracruzana, Campus Veracruz, Facultad de Administración y todos los miembros del equipo deberán estar presentes. La totalidad de las reuniones deberán ser documentadas mediante minutas de trabajo donde se presenten los temas tratados. Se plantearán 3 tipos de reuniones:

 Reunión de planeación del proyecto
Es la reunión inicial de planteamiento del problema, elaboración de propuesta de solución, asignación de actividades y responsabilidad, determinación de alcance, riesgos, limitaciones y productos a entregar.

 Reuniones de evaluación de avances
Estas reuniones se llevan a cabo de 3 a 5 días antes de la reunión de avance del proyecto con el cliente y consisten en la presentación de los avances de cada miembro del equipo, discusión de la situación del proyecto y evaluación de la calidad del avance.

 Reuniones de mitigación de riesgos presentados
Estas reuniones no se encuentran programadas y se llevaran a cabo exclusivamente ante la presencia de obstáculos durante el proyecto, así como posibles riesgos que se tengan que mitigar.

C. REUNIONES EXTERNAS

Las reuniones externas, son todas las que se llevan a cabo con el cliente. Si no es posible la presencia de todos los miembros del equipo, se asignará a un representante que se presente a la reunión, con los conocimientos totales de los puntos a tratar.

 Reunión de análisis de requerimientos
Es el primer contacto con el cliente para analizar la problemática y observar los procesos.

 Reuniones de propuesta del proyecto
Estas reuniones tienen la finalidad de acordar con el cliente los productos a entregar con el proyecto, fijar los plazos de entrega, el alcance del proyecto y la solicitud de propuesta. La cantidad de éstas dependerá de la conformidad del cliente con los documentos presentados.
 Reuniones de avance del proyecto
Estas reuniones serán programadas cada 15 días, y su objetivo es presentar al cliente los productos tangibles generados y el avance total del proyecto. En estas reuniones se presenta al cliente un documento de Avance del Proyecto y la evaluación del avance con respecto al cronograma de actividades.

 Reunión de entrega del proyecto final
Esta es la reunión final con el cliente, donde se hace la entrega de los productos finales.

4. ENTREGAS

A. LUGAR DE ENTREGAS

Todas las entregas de avances y producto final, serán realizadas en las instalaciones de la Universidad Veracruzana, Campus Veracruz, Facultad de Administración.
Dirección: Puesta del sol s/n
Fracc. Vista Mar.
C.P. 94292
Veracruz, Veracruz.

B. TIEMPO Y FECHAS DE ENTREGAS

Las entregas se realizarán en las reuniones de avance del proyecto (Anexo 4), o en cualquier otra fecha programada por el cliente. La duración de las entregas es de aproximadamente 30 minutos.

C. PRODUCTOS A ENTREGAR

Las entregas quincenales consistirán en los avances del proyecto, los cuales están especificados en la lista de actividades y entregables de los miembros del equipo en el Anexo 3. En éstas se presentará dos nuevos Capítulos traducidos, del libro Enterprise Integration, el cual se presentará en formato PDF y su presentación correspondiente elaborada en Power Point, presentada en formato PPT.

D. FECHA DE ENTREGA DEL PRODUCTO FINAL

La fecha de entrega del producto final será el día 18 de Junio de 2009, a las 11:00 a.m.

5. RECURSOS Y HERRAMIENTAS A UTILIZAR

Los recursos y herramientas utilizados durante la elaboración del proyecto, se encuentran definidas en el Anexo 5 del presente documento y se dividen como sigue:

Recursos
 Recursos Humanos
 Recursos Tecnológicos

Herramientas
 Herramientas software
 Herramientas de medición de la calidad
 Minutas de trabajo


III. SECCIÓN DE COSTOS

A. Mano de obra
Costo hora-hombre: $50
Recursos humanos: 2
Horas de trabajo: 180
Costo total de mano de obra: $1800

B. Alquiler de equipos o instalaciones
Costo renta de equipo de cómputo: $20 por hora.
Tiempo aproximado de renta de equipo: 10 hrs
Costo total de alquiler de equipos: $200

C. Transporte
Costo de transporte por persona: $12
Recursos humanos: 2
Visitas aproximadas: 8
Costo total de transporte: $192

D. Documentación
Papelería: $200
Impresiones: $500
Costo total de documentación: $700

E. Gastos indirectos
Costo aproximado de energía eléctrica por hora: $3
Horas trabajadas: $180
Gastos indirectos: $ 540

F. Costo total del proyecto
Costo de mano de obra: $1800
Costo de alquiler de equipos: $200
Costo de transporte: $192
Costo de documentación: $700
Gastos indirectos: $ 540

Costo total del proyecto: $2450

IV. SECCIÓN DE EVALUACIÓN

1. CRITERIOS DE EVALUACIÓN

Los criterios de evaluación interna del proyecto son definidos por la Lista de Verificación de características, definidas en el Anexo 2 del documento. Los criterios de evaluación externos serán establecidos por el cliente.


Veracruz, Ver. a 2 de Abril del 2009

_____________________________
Firma del Director del proyecto
Lia Nakid Cordero

_____________________________
Firma del Administrador del proyecto
Aralis Pegueros García


_____________________________
Firma del Cliente
Dr. Carlos Arturo Torres Gastelú


ANEXOS

Anexo 1. PRODUCTOS A ENTREGAR

Traducción del texto del libro Gold-Bernstein & Ruh (2005). Enterprise Integration. The Essential Guide to Integration Solutions (Boston: Addison-Wesley).

A. Características de contenido:

a. Se entregará la totalidad del libro en formato PDF.
b. Se entregarán los capítulos del libro por separado en formado PDF.
c. La traducción abarcará todo el texto del libro.
d. Los archivos incluirán todas las figuras, casos, esquemas y plantillas en inglés.
e. La traducción abarcará la totalidad del texto del libro de manera textual.
f. El mapa de integración se encontrará al final de cada capítulo con el recuadro sombreado correspondiente al capítulo siguiente.

B. Características de diseño:

a. La letra utilizada será Arial en color negro:
· Para los títulos se utilizará número de letra 14 en negritas.
· Para los subtítulos se utilizará número de letra 12 en negritas.
· Pare el texto se utilizará número de letra 12.
b. Las páginas tendrán encabezado con el nombre del capítulo en la parte superior izquierda y estarán numeradas en la parte superior derecha.
c. El texto estará justificado.
d. Los casos de estudio se encontrarán en un cuadro de texto color gris.

Anexo 2. MÉTRICAS

1. Lista de Verificación de Características.

Esta es la métrica utilizada para verificar que todos los elementos de calidad se encuentren en el contenido de las traducciones y de las presentaciones. Se utilizarán los siguientes formatos de tablas para verificar que el elemento esté presente, marcándolo con una “X” donde Si significa que el elemento existe y se encuentra completo, No significa que no se encuentra y Parcial significa que el elemento existe pero no está completo.

2. Evaluación de la Calidad del Contenido.

Estas métricas tienen como finalidad, el evaluar que el contenido y diseño de las traducciones y presentaciones para verificar que se encuentre completo y con las características definidas, además de considerar el adecuado diseño y presentación. En estas métricas se utiliza el formato siguiente para asignar una calificación a cada sección, donde 0 es la mínima calificación y significa que no se cumplió con el requisito y 5 es la máxima calificación e indica que todos los elementos están presentes, completos y bien elaborados.

3. Evaluación Alcance/Tiempo.

Esta métrica tiene la finalidad de llevar un control de las actividades realizadas y asegurar el cumplimiento y la entrega de los productos en la fecha programada. En caso contrario, la métrica servirá de documento de monitoreo de actividades y deberán justificarse los retrasos presentados. Se realizará un formato de evaluación para cada uno de los capítulos.

Tarea 5

Nombre del Proyecto

Elaboración de material didáctico para la Experiencia Educativa Sistemas Integrales en las Organizaciones.

Empresa cliente

Universidad Veracruzana
Dr. Carlos Arturo Torres Gastelú

Definición del problema

En la experiencia educativa Sistemas Integrales en las Organizaciones, no se cuenta con una bibliografía completa y didáctica en español, que se pueda tomar como fuente principal de consulta durante el curso. La bibliografía ideal que engloba la mayor parte de los conceptos necesarios a tratar en la experiencia educativa, es Enterprise Integration. The Essential Guide to Integration Solutions (Boston, 2005). Gold-Bernstein, Beth y Ruh, William. Addison-Wesley, sin embargo se encuentra únicamente en ingles. Se observó que los alumnos no cuentan con el dominio total del idioma, por lo cual hay diversidad de términos utilizados para un mismo tema, diferentes traducciones del texto e incluso, algunas veces se presentan textos sin coherencia o ilógicos.

Otro problema presentado es la falta de estandarización en el material de apoyo a las presentaciones, las cuales son diseñadas de manera diferente y en las que la información no es suficiente.

Estas problemáticas causan al alumno mayor dificultad en el entendimiento de la materia, así como la utilización de la mayor parte del tiempo en la realización del material, y no en el estudio de éste.

Propuesta de Solución al problema

La solución propuesta al problema anterior, es la elaboración del material didáctico para ésta experiencia educativa. Por Material didáctico se refiere a la traducción completa de la bibliografía Enterprise Integration. The Essential Guide to Integration Solutions (Boston, 2005). Gold-Bernstein, Beth y Ruh, William. Addison-Wesley, incluyendo todos los casos de estudio, ejemplos, figuras y plantillas expuestas por el autor. Cada capítulo se presentará en formato PDF, junto con una presentación en Microsoft Power Point, que cumpla ciertos estándares de calidad y diseño y cuente con la información más relevante completa y presentada claramente.

Justificación

Le traducción del libro Enterprise Integration y la elaboración de material para las presentaciones de cada capítulo, tienen la finalidad de solucionar la problemática presentada, así como de estandarizar el material utilizado durante el curso, asegurando la calidad del mismo para facilitar la comprensión por parte del alumno.

La finalidad de realizar una traducción, es evitar que el alumno pierda tiempo valioso en traducir el material, el cual puede ser utilizado para el estudio de la materia y desarrollo de proyectos, así como asegurar que la información sea la misma y se encuentre bien estructurada.
Por su parte, las presentaciones creadas en Microsoft Power Point para cada uno de los capítulos, asegurará que se encuentre en éstas toda la información relevante, diagramas, figuras, plantillas y casos presentados en la bibliografía.
Lo que se desea con la realización de este material didáctico y la traducción del libro, es la estandarización de la información para la experiencia educativa Sistemas Integrales en las Organizaciones, para que no existan discrepancias y se mantenga un cierto nivel de calidad en las presentaciones.

Objetivos

Objetivo general
Elaborar el material didáctico de la experiencia educativa Sistemas Integrales en las Organizaciones, para asegurar la veracidad de las traducciones y la completa estructuración de las presentaciones, estandarizando el diseño, la información y estructura; y también cubriendo ciertos requisitos de calidad.

Objetivos específicos
• Traducir el libro Enterprise Integration (Boston, 2007) Gold-Berstein & Ruh.
• Crear presentaciones en Microsoft Power Point completas y con información veraz.
• Definir la estructura y diseño de las presentaciones.
• Especificar los requisitos de calidad del material didáctico.

Metas/Entregables

El producto final consiste en una traducción completa del texto del libro Enterprise Integration. The Essential Guide to Integration Solutions (Boston, 2005). Gold-Bernstein, Beth y Ruh, William. Addison-Wesley entregado de forma completa y por capítulos, en formato PDF junto con las presentaciones en formato PPT de Microsoft Power Point de cada uno de los capítulos, contando con una estructura y diseño estandarizados.

Área de la empresa involucrada.

El involucrado es el catedrático encargado de impartir la experiencia educativa y que desee utilizar el material didáctico a lo largo de su curso.

Alcances

I. Traducción completa del texto del libro.
II. El libro incluirá todas las figuras, casos, plantillas y ejemplos.
III. Creación de presentaciones de power point estandarizadas por capítulos.
IV. Definición de estructura y diseño de todas las presentaciones.

Limitaciones

I. No se traducirán las figuras, diagramas y plantillas.
II. La traducción del libro no será publicada.
III. El material solamente abarcará la información incluida en el libro Enterprise Integration. The Essential Guide to Integration Solutions (Boston, 2005). Gold-Bernstein, Beth y Ruh, William. Addison-Wesley.

Costos estimados

Análisis de Requerimientos
Transporte: $12 x 2 = $24 por 10 visitas = $240
Entrevistas y Documentación: papelería $100
Costo horas-hombre: $ 50 x 5hrs = $250 por 2 personas = $500
Total: $840

Revisión de avances
Transporte: $12 x 2 = $24 por 10 visitas = $240
Total: $240

Diseño
Costo horas-hombre 50 x 5hrs = $250
Energía eléctrica: $100
Total: $350

Desarrollo
Costo horas-hombre 50 x 100hrs = $5000
Energía eléctrica: $100
Total: $5100

Reporte
Papelería= $400
Total: $400
Costo total aproximado del proyecto= $6930

Riesgos

• Las actividades requieren mucho tiempo, lo cual puede retrasar las entregas de avances.
• Aparición de nuevos requerimientos que no fueron identificados por el cliente al comienzo del proyecto.
• Retrasos en los avances que causen cuellos de botella en las actividades.
• Fallos en el recurso tecnológico utilizado para el desarrollo del proyecto.

Medidas preventivas

• Planeación minuciosa de los tiempos de realización de las actividades y los recursos con los que se cuenta.
• Mantener una constante comunicación con el cliente para asegurar que los requerimientos se cumplen de manera apropiada.
• Programar reuniones con el cliente para involucrarlo en el proceso y mantenerlo informado del progreso.
• Definir los actividades que realizará cada miembro del equipo, verificando desde el comienzo del proyecto que no falten requerimientos.

Tarea 5

Gep2009 Eq9 T5 Exp Anteproyecto

View more presentations from Lia Nakid.

Tarea 6

Introducción

Antes de comenzar un proyecto, se debe hacer un estudio para determinar la viabilidad del mismo y la rentabilidad futura esperada, más si se trata de un gran proyecto que se desarrollará en varios años y en el que se invertirán millones.

Ya que se determina que un proyecto es viable y se cuenta con la empresa contratista que lo llevará a cabo, es necesario que ambas, la empresa contratista y la empresa cliente determinen una serie de requisitos a cumplir en un contrato a lo largo del proyecto, así como los documentos necesarios para la Iniciación del mismo.

Una vez que se tiene un común acuerdo entre empresas, se celebran dos reuniones de lanzamiento. En el interno, que es dentro de la empresa que realizará el proyecto, se determinan los participantes principales, sus funciones, el objetivo del proyecto y las metas a lograr, entre otros. El externo, se realiza con el personal involucrado de las dos empresas y se acuerda la comunicación, necesidades, reuniones, se presentan a los participantes, entre otras cosas.

Finalmente, después de celebrar el Lanzamiento, se comienzan las labores y actividades necesarias referentes al nuevo proyecto y con esto concluye la fase de iniciación.

En la siguiente reseña del libro de Ángel Díaz Martín, David y Goliat. Iniciación del Proyecto (México, 2007) el autor se enfoca en la fase de iniciación de un proyecto, continuando con la novela relatada en la primera parte “David y Goliat. Las Tribulaciones de un Director de Proyectos” para ejemplificar el inicio de un proyecto, donde participan activamente las dos empresas involucradas, cada una con diferentes participantes para cubrir determinados puestos y actividades, así como los factores que se deben considerar al comenzar un proyecto, los puntos críticos que se deben solucionar primeramente y las relaciones jerárquicas entre los miembros del equipo del proyecto. Todo esto es narrado desde la perspectiva de un Director de Proyectos, que no solamente tiene que lidiar con la problemática de la iniciación del nuevo proyecto, sino también con su salida como Director del proyecto en el que se encontraba, y la toma de la decisión de la persona más competente para tomar su lugar.

Reseña

Díaz Martín, Ángel. (2007). David y Goliat, Iniciación del Proyecto. México: Alfaomega Grupo Editor.
Díaz Martín, una vez más nos envuelve en una entretenida novela acerca de una empresa contratista, que se encuentra administrando diversos proyectos, la cual está a punto de comenzar el proyecto más grande e importante que ha tenido. Esta es la segunda parte de la historia de David y Goliat, la cual es narrada desde la perspectiva del Director de Proyectos, el cual se enfrenta a una serie de problemáticas y obstáculos que se presentan durante la iniciación de un proyecto, así como los factores que desencadenan dichos problemas, explicando claramente los documentos necesarios para definir y dar inicio a un proyecto, los factores que se deben considerar, los participantes que estarán involucrados y las herramientas necesarias para llevarlo a cabo.

El relato, tiene lugar un lunes después de la serie de problemas que se le presentaron el viernes pasado (narrado en el libro 1), cuando regresa a la realidad de todos los pendientes que tiene por realizar. Al ir con el Director General, se percata que el cliente del proyecto Goliat, se comunicó a primera hora para tratar asuntos relacionados con la reunión del viernes anterior, lo cual significa que la empresa consideró contratarlos para que desarrollen su proyecto. Esto significa que David debe deslindarse del proyecto Alfa, del cual es Director actualmente, y decidir entre dos miembros del equipo capaces para desempeñar el cargo.

Al momento de tomar la decisión, el autor nos presentó una herramienta para evaluar a ambos miembros del equipo en la cual se ponderan sus habilidades para definir las actividades en que se desempeñan mejor.

David lidiaba con los problemas que presentaba el proyecto Alfa, el cambio de Director de proyecto y de Programador, pues éste último sería también substituido ya que colaboraría en el proyecto Goliat y encontró que la actitud del cliente del proyecto Alfa no era favorable, dado a que la naturaleza humana es reacia al cambio.

Mientras esto sucedía, David tenía que preparar al equipo del nuevo proyecto Goliat, así como los documentos a entregar al cliente con las estimaciones y solución a las principales preocupaciones, que eran: rentabilidad, permisos y equipos especiales.

Aquí el autor plantea tres posibles caminos que se presentan, en la rentabilidad, se podía establecer una hipótesis, sin embargo dependía de diversos factores; con los permisos, se identificaron los requerimiento fácilmente y no hubo mayor complicación; sin embargo, con los equipos especiales, se tenía que analizar minuciosamente la empresa a contratar debido a las diferencias presentadas por los dos posibles proveedores.

Al ser David un personaje responsable y perfeccionista, quería comenzar el proyecto Goliat de forma completa y bien definida, para evitar futuras sorpresas o complicaciones que pudieron ser prevenidas; y para esto consideraba la redacción de la Metodología de Gestión del Proyecto. Sin embargo, el Director del proyecto de la empresa cliente, no consideraba prioritario dicho documento y en diferentes ocasiones indicó a David que se pospondría hasta concluir con los puntos críticos. Esta pequeña circunstancia que plantea el autor, nos muestra como hay veces en que el cliente prefiere sacrificar unas cosas para solucionar lo que considera más importante, pero un buen Director de proyectos debe cumplir con los requerimientos del cliente y al mismo tiempo realizar un trabajo formal y seguir una metodología.

Desde otra perspectiva, el autor enfatiza de nuevo las características de los diferentes grados jerárquicos de la organización, de los miembros del equipo de proyecto, y añade las relaciones entre los dos equipos de proyecto, el del contratista y el del cliente. Se dan a conocer ciertas responsabilidades y las actitudes que toman los personajes, identificando cuáles de éstas son las adecuadas de acuerdo a su puesto y jerarquía, y cuáles no los son. Como en el caso de Monserrat, representante de una empresa que montaría las calderas, que paró en seco al Director de proyectos, lo cual no fue una forma adecuada de actuar, pero no fue del todo inaceptable debido a la preparación de la persona. No como en el caso de Pedro, quien tomo una decisión momentánea en la reunión de Lanzamiento con la empresa cliente, sin haber consultado previamente con el Director del Proyecto, el cual mostró su prudencia al no contradecir a sus subordinados frente al cliente, dándoles un grado de importancia.

Finalmente, es importante recalcar que cada personaje cuenta con una función muy específica, pues nos muestra los perfiles y habilidades que deben tener los miembros del equipo del proyecto dependiendo del puesto que ocupen y las actitudes que es recomendable evitar; de la misma forma se presentan ciertas actitudes tomadas por las personas ante diferentes circunstancias y posibles formas de abordarlas para contrarrestar el efecto. Con esto podernos concluir que el reto más grande y la causa principal de los riesgos en un proyecto, son las relaciones humanas.

Mapa Mental

Glosario de Términos de Gestión de Proyectos

1. Actividad: es una faceta de la psicología. Mediatiza la vinculación del sujeto con el mundo real. La actividad es generadora del reflejo psíquico el cual, a sus ves, mediatiza a la propia actividad.

2. Alcance del Proyecto: Son las acciones o tareas que se deben hacer para alcanzar los resultados o productos comprometidos. De esta forma a cada producto y lo resultado le corresponderá una acción o un conjunto de acciones determinadas y lógicamente relacionadas. Sólo se deben incluir aquellas acciones que realiza el equipo del proyecto. Para establecer el calendario y duración de ellas, se deberá tomar en cuenta la, disponibilidad y realidad sociocultural de los beneficiarios del proyecto.

3. Análisis de Riesgos: Conjunto de técnicas utilizadas para localizar los riesgos existentes en un proyecto a través de su identificación y la evaluación de sus efectos.

4. Análisis de Sensibilidad: Modo utilizado para conocer la incidencia de un determinado parámetro sobre los objetivos del proyecto: se dan diferentes valores a este parámetro y se calculan los indicadores que se crea conveniente.

5. Avance: Mención del progreso del proyecto, expresada por la división del coste previsto y el realizado para un proyecto.

6. Canal de Comunicaciones: Es el medio de transmisión por el que viajan las señales portadoras de la información que pretenden intercambiar emisor y receptor. Es frecuente identificarlo también como canal de datos

7. Ciclo de vida de un proyecto: Los proyectos son finitos: tienen un comienzo y final bien definidos, y en ocasiones parecen tener vida propia. En consecuencia, es lícito pensar que un proyecto tiene un ciclo de vida natural que consta de cuatro fases: concepción, formación, operación y terminación.

Concepción: Durante la fase de concepción se estudia la idea de realizar un proyecto. Si es beneficioso y factible, la idea se transforma en una propuesta de proyecto, y luego se toma la decisión de “realizarlo” o “no realizarlo”.

Documentación: En sentido restringido, la documentación como ciencia documental se podría definir (a grandes rasgos) como la ciencia del procesamiento de la información. Integradora y globalizadora, se trata de una ciencia enriquecedora y generalista, de ámbito multidisciplinar o interdisciplinar.

Formación: Durante la fase formativa del proyecto se definen con claridad los objetivos, se selecciona el tipo de organización y se asigna al administrador del proyecto. Luego, se transforma la propuesta en un plan de proyecto maestro y se elaboran en detalle programas, requerimientos de recursos y presupuestos.

Operación: En la fase operativa ya debe estar conformado el equipo de proyecto. En este momento comienza el trabajo en el proyecto.

Terminación: En la fase de terminación ya se debe haber completado el trabajo en el proyecto (o suspendido prematuramente). Durante esta fase se analizan los éxitos y fracasos del proyecto (incluida su estructura organizativa), se prepara un informe detallado para los equipos de proyectos futuros y se les asignan nuevas tareas a los miembros del equipo.
Coartada: Excusa buscada por alguien para justificar que no ha hecho un trabajo a tiempo o que su costo ha sido mayor del previsto.

8. Contratista: Es la persona o empresa que es contratada por otra organización o particular para la construcción de un edificio, carretera, instalación o algún trabajo especial, como refinerías o plataformas petroleras por ejemplo. Estos trabajos pueden representar la totalidad de la obra, o bien partes de ella, divididas de acuerdo con su especialidad, territorialidad, horario, u otras causas.
9. Cuadro de mando: Información resumida de la situación del proyecto. Contiene recursos, trabajo realizado en comparación a lo planeado, calidad del trabajo realizado, avance del proyecto previsto, coste actualizado, rentabilidad, máxima exposición al riesgo, valor probable del riesgo del proyecto. También se deben añadir: decisiones inmediatas a tomar, circunstancias externas, acciones correctoras, actitudes del personal, cohesión y grado de eficacia del equipo.

10. Entorno multiproyecto: En torno a un proyecto en una compañía, se realizan otros proyectos con los que los directores tienen que trabajar.

11. Equipo de trabajo: Personas con habilidades complementarias, propósitos y objetivos comunes que son cuantificables para el conjunto. Etapas para construirlo: formación, conflictos, normativa y resultados.

12. Estructura de desagregación del proyecto: Descomposición lógica y sistemática del proyecto en sus elementos constitutivos, sean tangibles o intangibles, que está orientada hacia el producto final.

13. Holgura: La holgura total es lo que se puede retrasar una actividad sin que altere la duración total de un proyecto, y la holgura libre es lo que se puede retrasar una actividad sin que quede afectada ninguna otra actividad del proyecto.

14. Homologación de suministradores: Es una buena política de empresa tener suministradores habituales. Ciertas empresas tienen sus registros de suministradores que catalizan constantemente a la luz de los nuevos requisitos y del comportamiento de los suministradores en los pedidos que les van cursando.

15. Indicador de satisfacción del cliente: Esta aceptado que la calidad a alcanzar en nuestros proyectos son los que satisfagan las expectativas de nuestros clientes. De ahí que es necesario medir su satisfacción para, como consecuencia, proceder a la evolución de nuestros sistemas de producción y de gestión, teniendo como horizonte la mejora continua.

16. Indicador económico del proyecto: Resulta del cociente de la suma del margen y la contingencia por el precio de venta: Iep = (margen + contingencia) / precio de venta.

Nos mide la bondad del resultado económico que vamos a alcanzar con el Proyecto que hemos contratado.

17. Informe de avance: Realizarse de acuerdo con los deseos del cliente y si no tiene una preferencia, basarse de uno estándar, pero debe contener la siguiente información:
· Resumen ejecutivo
· Seguridad y Salud
· Situación de las áreas de conocimiento
· Análisis de la situación
· Anexos
Debe acordarse el compromiso de entregarlo en determinado período de tiempo, y planificarse una reunión con el cliente para que se analicen los problemas y se haga la toma de decisiones.

18. Informe de gestión: Es complementario al informe de avance, y contiene, por encima de él, los datos que son internos de la empresa como costos, y análisis con respecto a las actuaciones ciertos actores en el proyecto.

19. Iniciación: Proceso básico de la Dirección de proyectos durante el cual se decide y autoriza el comienzo del proyecto.

20. Metodología de Gestión del Proyecto: Conjunto de normas, cubriendo las distintas situaciones que se puedan presentar, preparadas para realizar la correcta gestión de un proyecto.
Una vez elaborada es de obligado cumplimiento para todos los que trabajan en el proyecto.

21. Oscurantismo: El Oscurantismo es la sistemática oposición al progreso, al cuestionamiento de dogmas y a la difusión del conocimiento más allá de ciertos límites. El Oscurantismo es lo opuesto al Libre pensamiento y es con frecuencia asociado por sus opositores con los fundamentalismos religiosos.
22. Paquete de trabajo: Unidad más pequeña en la que se puede dividir un proyecto, de tal manera que el mismo se pueda gestionar razonablemente de una forma independiente.

23. Periodo de retorno: Plazo en el cual los flujos de tesorería actualizados a la tasa de referencia igualan al valor de las inversiones actualizadas a esa misma fecha. Si partimos de la hipótesis de los flujos de tesorería se generan al final del año, el periodo de retorno será un numero entero.
Cuanto mas bajo sea este indicador, a igualdad de los demás indicadores, mejor es el proyecto.
Da una idea de la velocidad a la que el proyecto recupera para la empresa la liquidez que ha inmovilizado al acometerlo.

24. Plan del proyecto: Es la documentación del proyecto, donde deben estar incluidas las contestaciones a cualquier pregunta que se pueda presentar durante su desarrollo, relativas a cómo hay que actuar ante determinadas circunstancias. Debe incluir descripción de todas las restricciones y riesgos que se puedan presentar, las hipótesis en las que está basado y la forma en que se va a documentar el progreso del plan y cómo se va a informar de ello.

25. Productividad: La productividad se define como la relación entre insumos y productos, en tanto que la eficiencia representa el costo por unidad de producto.

26. Reuniones de operaciones: Foro en el que se pueden tratar los problemas de los proyectos, en particular aquellos que aparecen cuando un proyecto entra en conflicto con otro.

27. Sistema de gestión del conocimiento: Base de datos de una empresa en la que se recogen sus conocimientos: explícitos e implícitos o tácitos, que los tienen las personas y que necesitan de una elaboración adecuada para integrarlos al sistema.

28. Tasa de rentabilidad interna: Tasa de documentos que igualan el valor de los desembolsos previstos con el valor de los flujos de tesorería esperados ambos actualizados.
Con este indicador en lugar de descontar los flujos de tesorería a una tasa prefijada, se obtiene aquella tasa de descuento que iguala el valor actualiza de los flujos esperados con las inversiones previstas.

29. Umbral: Valor predeterminado para un indicador de control de la gestión del proyecto. Pueden establecerse distintos grados de severidad. Cuando se sobrepasa el umbral, debe buscarse la raíz del problema, intentando paliar sus efectos.

30. Valor actualizado neto: Diferencia entre los flujos de tesorería actualizados a una tasa de interés prefijado y las inversiones actualizadas a esa misma tasa.
Un Van positivo indica que la inversión en el proyecto produce beneficios superiores a los que podrían obtenerse invirtiendo la misma cantidad a la tasa de referencia. Su valor positivo absoluto es el incremento patrimonial actualizado que experimenta la empresa para acometer el proyecto.

Bibliografía

Díaz Martín, Ángel. (2007). David y Goliat, Iniciación del Proyecto. México: Alfaomega Grupo Editor.

Lectura 4

Capítulo 1. Introducción

DESCRIPCIÓN GENERAL

Gestión de proyectos es administración. Su contexto y las limitaciones son diferentes de los de la línea gestión, pero su preocupación es la misma: dirigir un grupo de personas para lograr un objetivo. Por tanto, Directores de proyecto tienen que saber cómo manejar presupuestos, personas y procesos.

¿Por qué, entonces, muchas asignan técnicos superiores que suelen tener poco interés en o ineptitud para la gestión a la cabeza de los proyectos? Más críticamente, por qué hay tan pocos directores de proyectos en una industria que es impulsada por proyectos? Una de las razones es que las empresas tienden a considerar la gestión de proyectos como secundaria, no tan importante como la línea de administración o de conocimientos técnicos, y no una carrera objetivo para personas ambiciosas.

El resultado es que los fundadores de proyectos, la destrucción de los horarios, enredo en las estimaciones, descarrilar la carrera, y la obtención de resultados que son aceptados por la desesperación, más que por el diseño. A más largo plazo, los que han gestionado estos desastres se retiran de la gestión de proyectos y, o bien vuelven al mundo técnico o pasan a la administración "real". Por lo tanto, los directores de proyectos no se desarrollan, y el ciclo continúa.

Son los directores de empresas, gestores de proyectos y personal técnico quienes entienden que la gestión del proyecto es una disciplina especial, a la que este libro está dirigido.

CONTEXTO DE LA GESTIÓN DE PROYECTOS

Gestión de proyectos es la gestión, pero cinco características la hacen única: la responsabilidad sin autoridad, su fuente de poder, transitoriedad del proyecto, la observación de “Se obtiene lo que se consigue”, y la necesidad de herramientas y técnicas especializadas.
Responsabilidad sin autoridad

Un director de proyecto, es responsable de un proyecto. Si no cumple con el presupuesto, el calendario, o expectativas, son los que tendrán que rendir cuentas y que, como mínimo, sufrirán las llamadas de atención de la administración y recibir una evaluación de la actuación profesional desfavorable.

Llevar un proyecto al objetivo requiere de recursos: las personas, equipos y servicios de apoyo. Sin embargo, con raras excepciones, los directores de proyectos no administran los recursos. No se puede asignar arbitrariamente al personal a los proyectos, adquirir equipo cuando se necesite, contratar a personas, o poner las necesidades personales en la parte superior de la lista de prioridades de la empresa. Tampoco puede promover o despedir personal. Esas prerrogativas pertenecen a los supervisores y la línea directivos.

Para adquirir recursos, el Director del proyecto debe hacer caso a alguien que tiene autoridad. Con mucha frecuencia, esa persona considera esas peticiones, como prueba de incapacidad o mal juicio.

La Fuente de Poder
A pesar de la falta de autoridad formal del director del proyecto, la posición lleva consigo un poder considerable para los que estén dispuestos a ejercerla. La fuente de poder que es la realidad de que el gerente de proyecto es el único capaz de hacer que el proyecto tenga un valor, sin un director de proyecto, el proyecto se encuentra en extremo peligro. El ejercicio de este poder es la disposición de un Director a retirarse de un proyecto bajo condiciones extremas. Tienen el derecho y la obligación, de decir a un cliente o a la administración, "Este proyecto no puede tener éxito en estas condiciones, y hasta que no se cambien, no se puede continuar."
Obviamente, esta es una posición que requiere de circunstancias anormales, No se usan para los problemas que día a día acompañan a la mayoría de los proyectos. Igualmente, se tendrá que considerar la situación personal y profesional de las consecuencias de tomar una posición tan fuerte. Sin embargo, no está obligado a aceptar pasivamente todas las condiciones que imponen los clientes o la administración, y en la mayoría de las organizaciones una negativa a aceptar demandas innecesariamente difíciles sirve como un tratamiento de choque, lo que indica que un problema existe y debe abordarse.
Transitoriedad del proyecto
Los equipos, y no los directivos, son los que ejecutan proyectos. Por lo tanto, una de las principales tareas de un Director es la creación de equipos. Esto también es necesario en la administración de la empresa, pero la diferencia es que mientras perduren los departamentos, los proyectos son de carácter temporal. El Director debe aplicar habilidades de equipo a un grupo de personas que pueden no tener compromiso con el proyecto y que pronto pasaran a otro proyecto. No tiene el lujo de permitir a un equipo evolucionar, lo debe crear el mismo.
Se obtiene lo que se consigue
Algunos teóricos de la gestión de los proyectos hacen hincapié en la importancia de seleccionar un buen equipo de proyecto, que concuerden las habilidades con las actividades, e incluso que engranen con las personalidades. Lamentablemente, las empresas no tienen un enorme grupo de personas con los conocimientos técnicos a la espera de ser elegidos como si se tratara de un juego de béisbol. El problema al que se enfrentan la mayoría de los directores de proyectos no es la elección de las personas adecuadas, sino las que son remotamente calificadas. Su trabajo no es para seleccionar un equipo de proyecto, sino para construir uno partiendo de las personas disponibles.
Herramientas y técnicas especializadas
La gestión de los proyectos tiene su propio conjunto de herramientas y técnicas. Conceptos tales como estructura de desglose de trabajo, nivelación de recursos, y los estimados totales son en gran medida desconocidos fuera de ésta disciplina. Incluso las técnicas, tales como diagramas de Gantt o camino de análisis crítico, se han vuelto común que en los negocios no se utilicen tan ampliamente en la práctica empresarial como en la gestión de los proyectos oficiales. No es fácil aprender estos conceptos o de entender cómo aplicarlos, sobre todo porque son pocas las empresas que las aplican coherente. La tendencia a considerar la gestión del proyecto como de importancia secundaria provocará que las empresas contrataran a Directores de proyecto para formar a su personal en esa área. Además, es necesario que las mismas herramientas y técnicas sean utilizadas por todos los gerentes. Un gerente de proyecto o de un superior jerárquico, necesita saber cómo escuchar, marcar de resultados, organizar de reuniones, reunir información, construir equipos, comunicar y gestionar su tiempo.

Sin embargo, rara vez reciben los directores de proyectos de gestión reciben formación, ni son seleccionados, como los directores por la administración comprometedora, aptitudes o comportamientos.

Estas cinco características hacen que la gestión de los proyectos requiere, en todo caso, la gestión de más habilidad que la mayoría de las líneas de gestión. Gestión de proyectos es una disciplina que requiere aptitud, normas, y la formación adecuada. Sin esto, se asegura que los sistemas de los proyectos sufrirán sobrecostos, retrasos, y aumento de la antipatía de los usuarios y de los empresarios, que contradictoriamente están cansados de relación con "los sistemas de servicio”.

¿QUÉ ES UN PROYECTO EXITOSO?

Un proyecto exitoso es aquel que ofrece los resultados esperados. Estos incluyen tradicionalmente ajustarse a un presupuesto, a un cronograma y un alcance de la gestión de proyectos. Todo proyecto que cumpla con estas medidas es, por esta definición, un éxito. De hecho, muchos gestores de proyectos se consideran exitosos si son capaces de lograr dos de los tres.

Sin embargo, el presupuesto, cronograma, y el alcance son técnicas que definen la forma métrica en que el proyecto fue gestionado, y tienen poca relación con las preocupaciones reales del cliente.

Un proyecto es ejecutado por el cliente espera algún beneficio, como la reducción de los niveles de inventario, la reducción de personal o el aumento de las ventas anuales. El proyecto puede ser ejecutado perfectamente, llegando a tiempo y dentro del presupuesto, haciendo lo que se supone que, pero en realidad no reducir inventario, reducir personal, o aumentar las ventas por lo menos suficiente para cubrir el costo del proyecto, entonces el dinero que gasta el cliente se pierde.

Por ejemplo: Una empresa con 10 millones de dólares presupuestados en inventario y 100.000 dólares para un sistema de control de inventario, espera reducir el inventario en un 20%, o 2 millones de dólares. En el 10%, el sistema de corte traerá costos por 200.000 cada año, por lo tanto el proyecto sufrirá un 100% de sobrecostos.
Si la empresa no aplica el sistema o lo hace pero no para reducir su inventario, ha perdido $ 200.000, es decir, el costo presupuestado y el rebasamiento. Pero si la empresa no aplicar el sistema y los recortes de inventario como se esperaba, recuperarán el costo de ese rebasamiento en apenas seis meses, y se pagará por todo el sistema en un año. Esto no es raro: Los beneficios de un sistema normalmente superan incluso devastadores sobrecostos, debido a esto, el sistema debe aplicarse y los beneficios serán alcanzados.

Esto no es un argumento para ignorar el proyecto de presupuesto, es un recurso para que se acepte la responsabilidad de ayudar a los clientes obtener los beneficios que justifican el proyecto. El Director de proyecto debe estar más interesado en la entrega de beneficios que en la entrega del sistema.

¿POR QUÉ FRACASAN LOS PROYECTOS?

Historias de fracasos abundan. Un proyecto que se había presupuestado en 10 millones de dólares finalmente se canceló cuando pasó a 100 millones de dólares. Un sistema que se debió entregar a finales de julio, se entregó a finales de septiembre dos años más tarde. ¿Por qué estos y menos extremos, pero igualmente frustrantes fracasos acechan a la industria?
El más comúnmente citado es culpable mala estimación. Es la sabiduría convencional de que personal técnico no puede estimar el costo de la comida, incluso teniendo un menú para trabajar, pero esta explicación es un mito. Naturalmente, hay malos estimadores, pero incluso si toda la estimación se fuera por el 100 por ciento, el coste total seria más del doble. Esto no es deseable, pero tampoco es comparable con los sobrecostos de la empresa.

De hecho, la mayoría de la gente puede estimar razonablemente bien y, en un gran proyecto, el optimismo de algunos estimadores está bastante bien equilibrado por el pesimismo de otros. De hecho, existen tres motivos recurrentes por el que los proyectos fallan: cambios de alcance, la mala planificación del proyecto, y la tecnología.

Cambios de alcance son probablemente la principal causa de fracasos puesto que no es simplemente el añadir los costos, sino que se deben añadir de forma proporcional a su esfuerzo.

Por ejemplo, un proyecto estimado en 1 millón de dólares se convierte en un proyecto que, de haber estado planeado que desde el principio, se habrían estimado 2 millones de dólares. Es tentador creer que el coste final del proyecto será de unos 2 millones de dólares, pero será más cerca de $ 4 ó $ 5 millones, porque los cambios de alcance alteran la planificación y el desarrollo que ya se concluyó.

Los cambios de alcance son un problema por dos razones. O bien el alcance no estaba claramente establecido al inicio del proyecto o se hace una mala gestión de los cambios. Sin embargo, éstos son un hecho de la vida del proyecto y pueden ser perjudiciales cuando no son manejados adecuadamente, es decir, cuando no están adecuadamente definidos, controlados y gestionados.
La segunda causa importante del fracaso de los proyectos es la mala planificación y, en particular, la revisión de las actividades del proyecto durante la planificación. Estas actividades no son parte de las estimaciones y no aparecen en el calendario pues no tienen ningún efecto en el plan, pero cuando aparecen, pueden provocar el caos.

La tercera de las razones principales de que los proyectos fallen es la tecnología y el exceso de herramientas en el entorno de desarrollo de un proyecto. Todas estas herramientas deben caber dentro de un sistema operativo, todos vienen con una multiplicidad de opciones y versiones, y todas son adquiridas de diferentes proveedores. Las empresas que seleccionar un entorno de desarrollo y lo mantienen durante un período razonable, son recompensados por el aumento de la productividad y predicción en los proyectos. Lamentablemente, muchas empresas tienen la idea de que su entorno de desarrollo se ha convertido en arcaico y que esta herramienta resolverá sus problemas. El resultado es el contrario, porque en primer lugar, la productividad sufre porque los desarrolladores nunca crean experiencia en un ambiente y en segundo lugar, los proyectos sufren porque, las nuevas piezas no funcionan con algunos de los sistemas antiguos y pueden pasar meses tratando de conseguir que todos funcionen.

Los proyectos no tienen que fallar. Cuando los administradores y equipos de desarrollo toman en serio la forma de planear y llevar a cabo los proyectos, generalmente tienen éxito.

CONTROL DEL MEDIO AMBIENTE DEL PROYECTO

Una medida del éxito del proyecto es la dl ambiente de gestión del proyecto dentro de la empresa. Muchas compañías simplemente entregan proyectos a cualquier persona para que los lleve a cabo y esperan que funcionen o que al menos provean algún beneficio. Pero las empresas que generalmente tienen éxito son las que establecen estructuras y procedimientos de apoyo a los administradores del proyecto.

ESTRUCTURAS DE INFORMES DE CAMBIOS

¿Qué requisitos para la presentación de informes del estado del proyecto se establecen a los administradores de proyectos? ¿A quién informes de situación ir? ¿Con qué frecuencia? ¿Qué tiene que decir? ¿Qué seguimiento se llevará a cabo sobre las cuestiones planteadas en el estado informes? ¿Por quién?.

Hasta que no se responda a estas preguntas, el reporte será inadecuado. Mientras que a muchos administradores de proyectos no les gusta preparar el estatus de los reportes, el único entorno que no los requiere es cuando la administración desaprobó el proyecto o no intervenir, salvo para culpar cuando las cosas van mal. La existencia de buenas normas de reporte es una indicación de que la gestión de cuidados sobre la marcha de los proyectos y, en consecuencia, ayuda cuando es necesario.

Otro componente de los informes de estructura es la escala de procedimientos. Cuando los problemas tienen que ser aumentado, ¿cuál es el procedimiento para hacerlo? ¿A quién debe abordar la cuestión? ¿Cómo? ¿Con qué expectativas? Las empresas que han definido los procedimientos de escalada reconocen que algunas cuestiones requieren intervención de altos niveles y han definido un mecanismo para que las proporcionen. Cualquier gestión que no permite la escala, no se preocupa por el proyecto.

TRAYECTORIA DE ADMINISTRADORES DE PROTECTOS

Las empresas que cuenta la gestión de proyectos como importante nutrimento para las personas que son responsables, garantizan que los directores de proyectos tengan una carrera clara y conveniente que incluye la formación, criterios de promoción, reconocimiento de los logros, y la oportunidad de progreso a los más altos niveles ejecutivos en la organización, esto es por el reconocimiento de que la gestión del proyecto es una disciplina, es necesaria, y que es digna de fomento. Estas son las empresas que, a su vez, atraen, desarrollan y mantienen a los mejores profesionales de la gestión de los proyectos disponibles.

¿COMO SABER SI SE TIENE UN PROYECTO?

Cuando la gente habla de los proyectos, generalmente hablan de costosos, visibles y grandes proyectos que caracterizan el desarrollo de los sistemas. Algunos dirán que estos no requieren de un cierto nivel de gestión, ¿Pero qué pasa con las pequeñas actividades, las que obviamente no son tan arriesgados o crítica a la organización? ¿Se requiere la atención de un director de proyecto Cuando se hacen estos proyectos?

Por ejemplo, el hardware se está mejorando con más memoria, más capacidad de disco y una nueva versión del sistema operativo. ¿Se trata de un proyecto, o puede ser dejado a los sistemas simplemente a la gente a hacer el trabajo sin imponer una estructura de proyecto en ellos?

Hay un área gris entre las actividades que forman parte de un diario de actividades y responsabilidades que constituyen un proyecto. Como consecuencia, muchas organizaciones han luchado con la pregunta "¿Cómo saber cuando tenemos un proyecto?. El Anexo 1.1 proporciona un conjunto de criterios y una lista de verificación que debe ayudar a proporcionar una respuesta.

· Las actividades se involucran más de dos personas.
· Las actividades se requieren más de dos semanas de esfuerzo.
· Las actividades se requieren más de un mes, transcurrido el tiempo.
· Las actividades que impliquen riesgo.
· Si no las actividades, habrá un impacto significativo.
· Las actividades requieren la coordinación de dos o más departamentos.
· Las actividades implican fuera socios.
· Las actividades se involucran nuevas tecnologías.
· Las actividades que quedan fuera del alcance de las operaciones normales.
Exposición 1.1: Criterios de Definición del proyecto

Si dos o más puntos se identifican, en particular los que implican la coordinación o de riesgo, entonces las actividades son un proyecto. Puede que no sea grande, ni que ocupe gran parte del tiempo de un experimentado gestor de proyectos, pero si no se gestiona adecuadamente, la empresa está en algún grado de riesgo.

Uno de los obstáculos a la simple definición de conjuntos de actividades, es la sobrecarga que impone un proyecto. La tentación es decir, "Vamos a saltar la burocracia y dejar que la gente empiece con el trabajo". Esto es atractivo, y sucede en la mayoría de los casos, que los pequeños conjuntos de actividades se hacen discretamente. Sin embargo, consideran los riesgos y los costos en los siguientes ejemplos:

Una actualización de hardware esta prevista antes de fin de mes y ésta es necesaria a fin de completar los informes de fin de mes a tiempo, pero para la instalación del nuevo hardware era necesario apagar el sistema, y nadie había hablado con los usuarios. El usuario gerente se niega a permitir el cierre sin dos semanas de aviso para cambiar el tiempo del personal. El resultado es que los informes de fin de mes se retrasan debido a la falta de capacidad y la empresa pierde negocios.

Una nueva versión del sistema operativo se instala, dado que la solicitud había sido aprobada con éxito y se realiza en la noche listo para el día siguiente, pero esta versión requiere cambios en las tablas del sistema de red, y nadie había notificado a la red de apoyo. Por el momento el problema fue corregido pero la producción experimenta cuatro horas de tiempo de inactividad.
El objetivo de la gestión del proyecto es reducir el riesgo y garantizar la entrega oportuna. Como estos ejemplos ilustran, los problemas no se limitan a los proyectos con un presupuesto elevado. Todo lo que podía salir mal merece ser gestionado.

EL PAPEL DE UNA OFICINA DE GESTIÓN DE PROYECTOS

Hasta hace poco, la mayoría de las organizaciones trataban la gestión de proyectos como una cuestión de preferencia individual. Envían a sus jefes de proyecto a un curso o, más ambiciosa, a un programa de certificación, pero, a su regreso, los administradores del proyecto actúan por su propia cuenta para los proyectos que eligieron. Las organizaciones tienen que apreciar que existen dos principales problemas con este enfoque:

1. Gestión de proyectos es una disciplina. Los que no ejerzan los principios de esta disciplina verán sus proyectos colapsados. Por lo tanto, la eficacia del proyecto ces directamente proporcional a las variaciones en la formalidad.

2. Cuando los directores de proyectos salen de la organización o se transfieren a otro proyecto, es muy difícil para sus reemplazos hacerse cargo, porque la documentación del proyecto se ajusta a las preferencias personales del administrador, en lugar de a una documentación estándar.

Algunas organizaciones, en un intento de crear normas, adquieren metodologías que proporcionar una estructura y coherencia a los proyectos. Sin embargo, las buenas intenciones son víctimas de tres problemas:

1. La mayoría de estas metodologías se centran en las actividades de los proyectos propios como el desarrollo, en lugar de sobre cómo los proyectos se gestionen. Como tal, su utilidad en el establecimiento de proyecto de normas de gestión es mínima.

2. Las metodologías se ocupan principalmente de los proyectos de desarrollo de aplicaciones, haciendo caso omiso de los proyectos en otras áreas de TI tales como infraestructuras o la planificación estratégica.

3. Cualquier metodología es tan buena como su grado de uso. Los administradores no utilizan de una metodología, cuando los directores de proyectos la aprueban incompatible. Entonces, ¿cómo hace una organización para crear y hacer cumplir las normas? La respuesta que está ganando una amplia aceptación es el proyecto de gestión de oficina, o PMO, un departamento de la empresa responsable de la práctica y la disciplina de gestión de proyectos dentro de la organización, o al menos en esa parte de la organización que corresponde al ámbito de su control.

La PMO varía en las diferentes organizaciones. Algunas son poco más que grupos de apoyo que prestan asistencia y directrices, pero que no tienen ninguna autoridad, mientras que otros son el verdadero control de la gestión de los departamentos con la responsabilidad para el éxito del proyecto. Un PMO puede informar desde a un Director de TI o de una ingeniería, de las organizaciones en la gestión de los proyectos que se consideran estratégicos, todo el camino hasta el nivel ejecutivo, e incluso a la CEO.

Las funciones de una PMO pueden variar, pero generalmente se dividen en tres categorías:

1. Funciones de desarrollo
Son las que construyen un grupo de gestores de proyectos eficaces. Entre ellas se incluyen actividades tales como la contratación de personal, la gestión del proyecto la definición de orientaciones y formaciones profesionales, proporcionando apoyo y asistencia a los directores de proyectos, gestores de proyectos y la evaluación al final de un proyecto.

2. Funciones de apoyo
Son los gestores de proyectos que ayudan a ser más eficaz en su administración. Entre ellas se incluyen actividades tales como el tiempo de reunión y presentación de informes, la definición de normas para los documentos del proyecto, el establecimiento de prioridades entre los proyectos, se establecen los procedimientos para tales cuestiones como el ámbito de aplicación o de control de revisión y aprobación, la creación de normas para la iniciación y cierre proyectos, la aplicación de metodologías de gestión de proyectos y programas informáticos, y ofrecer un mediación para la solución de controversias.

3. Funciones de control
Son aquellas que proporcionan la línea de gestión a los directores de proyectos. Entre ellas se incluyen promoción de la supervisión de los empleados, proporcionando disciplina y la dirección, la definición de normas obligatorias tales como la frecuencia de los informes o reuniones de equipo, y la revisión de proyectos en curso.

Las organizaciones que han implementado efectivos PMOs, han encontrado que su coherencia del éxito del proyecto mejora y que su capacidad de proporcionar a sus gestores de proyectos un crecimiento profesional y la formación que les permite crear un grupo de expertos y personas cualificadas que se han comprometido y son capaces de proporcionar valor a sus organizaciones, garantizando que sus proyectos tengan éxito.

ALGUNAS OBSERVACIONES SOBRE CICLOS DE VIDA DE PROYECTOS

El desarrollo del ciclo de vida se refiere a cómo se ha efectuado el trabajo; la gestión del proyecto se ocupa de hacerlo.

La gestión de proyectos no depende de ningún Sistema de Desarrollo del Ciclo de Vida del Proyecto (SDLC) o enfoque de desarrollo. Un Director de proyecto, debe asegurarse de que sabe cómo va a alcanzar el objetivo final del proyecto, y un SDLC viable puede ayudar, pero los buenos gerentes de proyecto pueden manejar cualquier enfoque. Además, asociado a la gestión de proyectos con un SDLC es ignorar (o rechazar) la evolución de las formas para desarrollar sistemas. El convencional modelo "cascada" está siendo sustituido por conceptos tales como el rápido desarrollo de aplicaciones, la evolución de prototipos, diseño de refinamiento iterativo, y la "espiral" de enfoque. Incluso SDLCs convencionales están siendo utilizados con mayor flexibilidad.

Por último, SDLCs están destinados principalmente a proyectos de desarrollo de los sistemas que producen código y hace caso omiso a otros tipos de proyectos, tales como la definición de los requisitos de las aplicaciones, la aplicación de los principales paquetes, la actualización de hardware, el diseño de una arquitectura de la tecnología, los sistemas o el desarrollo de un plan estratégico. Gestión de proyectos es una disciplina que se aplica a cualquier proyecto, independientemente de su SDLC, y de su enfoque técnico.

GESTIÓN Y PARTICIPACIÓN

En muchas organizaciones, el "jefe de proyecto" es también un equipo participante, del que se espera la producción de proyectos, así como su gestión. El director del proyecto también espera que participen en la gestión y, a menudo, varios proyectos a la vez.

El problema de pedir a un técnico para la gestión de un proyecto, así como a participar como miembro de un equipo es que la gente tiende a hacer lo que les interesa, y qué intereses técnicos es la tecnología. Cuando el proyecto tiene inconvenientes y el equipo está empezando a poner en tiempo extra para mantenerse al día con el calendario, ¿cómo se puede criticar a un superior jerárquico de un empleado por no preparar un informe de situación cuando esa persona es la creación de sesenta horas semanales en el desarrollo técnico?

DIRECTOR DE PROYECTO Y MIEMBRO DEL EQUIPO

Si se le pide a una persona gestionar un proyecto para producir resultados favorables, necesitará algunas directrices para asegurar que tiene tiempo para la nueva responsabilidad. En primer lugar, comprender las demandas de tiempo de gestión de proyectos. Normalmente, un director de proyecto tendrá alrededor de 15 por ciento del esfuerzo total del proyecto técnico. Esto variará dependiendo de la complejidad del proyecto y la experiencia, pero, en general, si el esfuerzo técnico del proyecto es de 1000 horas, el proyecto esfuerzo de gestión será de 150. Por lo tanto, es preciso conocer el esfuerzo total del proyecto a fin de que, al asignar su carga de trabajo y dejar tiempo suficiente para llevar a cabo la gestión de las tareas del proyecto.
En segundo lugar, es mayor en el período de realización del proyecto, por lo tanto, el debe dedicar todo su tiempo al proyecto durante la gestión de la planificación y las etapas de cierre. En el centro del proyecto, el tiempo que se necesitará para supervisar las actividades en curso serán más bajos, alrededor de 10 por ciento del esfuerzo total del proyecto. Así, por ejemplo, si el proyecto tiene tres personas que producen los productos, da un total de 120 horas a la semana. El director tendrá que dedicar 10 por ciento. Si el tamaño del equipo de proyecto llega a diez personas a tiempo completo, trabajarán un total de 400 horas cada semana, y tendrá que dejar de lado a 40 horas su gestión. Eso es a tiempo completo sin disponibilidad para trabajar en otro proyecto.

GESTIÓN DE MULTIPLES PROYECTOS

Experimentados gestores de proyectos más pequeños pueden gestionar varios proyectos simultáneamente, sin afectar la calidad de su trabajo. Los principios que se aplican a la gestión de los proyectos individuales se aplican a la gestión de los múltiples.

Estos proyectos todavía necesitan inicio, la planificación, gestión y liquidación. El único problema adicional al que se enfrenta en la gestión de más de uno de los proyectos, es la determinación del tiempo y establecer prioridades. Sin embargo, los consejos dados anteriormente para la gestión y la participación se aplican a la gestión de múltiples proyectos.

Sin embargo, existen algunas otras consideraciones en la gestión de múltiples proyectos. En primer lugar, hay una elevada carga de trabajo durante la planificación y el cierre del proyecto. Por lo tanto, es necesario asegurarse de que estas etapas tendrán lugar en momentos diferentes en los distintos proyectos que están manejando. Esto se da en la gestión de múltiples proyectos, donde no es necesario entregar productos específicos en los proyectos. De lo contrario se debe calcular 10 por ciento de la suma de todos los esfuerzos en todos los proyectos en ejecución y de tiempo completo durante la planificación de cierre y que la licencia de tiempo suficiente para actuar como un punto de vista técnico así como participante.

ALGUNAS NOTAS SOBRE TERMINOLOGÍA

En este libro, se utilizan los siguientes términos:

Cliente
El cliente es la empresa o departamento que se especifique lo que el proyecto es llevar a cabo, paga la factura, y acepta la entrega del sistema. El cliente puede ser un cliente externo, como el de una consulta empresa o un departamento interno. El cliente está representado por el personal del cliente. Entre ellos se encuentran los administradores de clientes o usuarios y los encargados de adoptar decisiones. Cuando este libro se refiere a un cliente como una persona, se refiere a la más alta jerárquicamente.

Director
El director del proyecto es la persona responsable de la programación, presupuesto, funcionalidad y aplicación de un proyecto o subproyecto. Muchas organizaciones diferenciar entre los directores de proyectos y jefes de proyecto, pero la diferencia es una de la nomenclatura y, a veces, el tamaño del proyecto. No es una de las responsabilidades.

Proyecto

Un proyecto es un conjunto de actividades que ha definido claramente un inicio y final y que produce un producto tangible. Un proyecto puede producir un nuevo sistema de solicitud o de una importante mejora. También puede proporcionar actualizaciones de paquetes de software, hardware actualizado, informes y análisis, tales como los requisitos de las aplicaciones, una tecnología de arquitectura, un plan tecnológico estratégico, o de un plan de reingeniería.

Usuario

Los usuarios son las personas que realmente utilizan los resultados de un proyecto. Para la mayoría de los proyectos, los usuarios forman parte de la empresa cliente, encargada de especificar los requisitos del proyecto.

ACERCA DE ESTE LIBRO

Cualquier proyecto tiene cuatro fases distintas: la comprensión del proyecto, la definición de que, la planificación, y gestión. En todas estas etapas, se deben ejercer las competencias generales y especializadas y habilidades de gestión de proyectos dentro del contexto descrito anteriormente. Una imagen de la gestión del proyecto se vería similar a lo que se ve en el Anexo 1.2.

Exposición 1.2: Descripción de la Gestión de Proyectos

Este libro consta de las siguientes cinco secciones:

1. "Introducción" establece el marco y el contexto para el libro.
2. "Comprensión del proyecto" describe lo que usted necesita entender acerca de un proyecto que está a gestionar y qué papel puede tener en la configuración de un proyecto desde el principio.
3. "Definición del Proyecto" listas de las cosas que usted necesita para definir, entre ellos los resultados, el alcance y cómo va a gestionar el proyecto.
4. "Planeación del Proyecto" se refiere a las técnicas de planificación de la gestión del proyecto, incluyendo cómo descomponer un proyecto en las actividades; cómo preparar un presupuesto, un presupuesto y un calendario; cómo plan de recursos, y cómo identificar los riesgos.
5. "Ejecución del Proyecto" se presenta el día a día las actividades necesarias para mantener el proyecto en marcha, incluyendo cómo construir equipos eficaces, la forma de seguimiento de los progresos y programa de gestión de desvíos, y cómo manejar las solicitudes de cambio alcance. También trata de cómo gestionar y subcontratistas equipos cliente.

El proyecto ideal, tendría que pasar secuencialmente a través de las etapas de la comprensión, la definición, planificación, y ejecución. Sin embargo, se puede elaborar un plan de trabajo (véase Anexo 1.3). En éste las flechas marcan el flujo normal de la obra, y los más pequeños indican que el proceso es iterativo. A lo largo de toda la proyecto, que será siempre de regresar a etapas anteriores del proyecto como las condiciones cambian.

Exposición 1.3: Plan de Gestión de Proyectos

La hoja de ruta también actúa como una lista de verificación. Si se puede responder sí a todas las preguntas que presenta, tiene el proyecto bajo control. Hallows ofrece una metodología que sirve como una guía de referencia para la gestión de proyectos de sistemas. Se trata de un conjunto de herramientas cuyas piezas se van utilizando como la situación lo requiere.

Capítulo 2: Comprensión del Proyecto

La gestión de los proyectos que requiere la toma de decisiones, el entendimiento del medio ambiente y de las personas. En otras palabras, el Director del proyecto necesita entender el contexto cultural y político de éste. Si ha sido nombrado gerente del proyecto debido a su antigüedad técnica, una de las tentaciones que deben superar es centrarse en las cuestiones técnicas y no en los que consideran "políticas" y la responsabilidad de los demás, pues las personas involucradas en los proyectos es más importante que el aspecto técnico.
Para gestionar un proyecto, se necesitan entender cuatro cosas:

¿Por qué es este proyecto que se está realizando? ¿Qué es lo que el cliente espera obtener de ella?
¿Cuál es el trasfondo de este proyecto? ¿Cómo hemos llegado a donde estamos?
¿Quiénes son los actores? Que ha luchado por este proyecto? Que ha luchado en contra de ella? ¿Quién es el patrocinador ejecutivo?
¿Cuáles son las prioridades del cliente para este proyecto?

Estas preguntas reflejan distintas maneras de obtener una comprensión del proyecto, ya que éste incluye una mezcla dinámica de las personas con intereses diferentes, filosofías, valores, enfoques y prioridades. Una de las principales funciones del gerente del proyecto es asegurar que esta mezcla sea coherente y conduzca al proyecto.

Responsabilidad fiduciaria

La gestión del proyecto no es fácil, ni dependen de manera acrítica agradable al cliente. A veces, el bien de que el proyecto requiere que el cliente tome decisiones o acciones y oponga a las situaciones de riesgo. El administrador del proyecto, es su representante. Esta función es común en las empresas y ejecutivos de los miembros de la junta puede ser considerada legalmente responsables de ejercer su "responsabilidad fiduciaria" para actuar en nombre de su empresa. También debe aceptar que tiene una responsabilidad fiduciaria para actuar en nombre del proyecto.

¿POR QUÉ LLEVAR A CABO UN PROYECTO?

Sólo hay una razón válida para gastar dinero en un proyecto: generar o ahorrar más dinero que los costos. Lamentablemente, hay una confusión entre el objetivo del proyecto y su justificación. El objetivo de un proyecto es una declaración general acerca de por qué se lleva a cabo. Tal declaración podría ser:

El objetivo de este proyecto es crear un estado de la técnica, en línea, en tiempo real, sistema de inventario que nos permitirá gestionar nuestro inventario más de cerca al mismo tiempo para satisfacer las demandas de nuestros clientes.

La declaración de este objetivo, a pesar de la alta tecnología de moda, es clara: Vamos a construir un sistema que gestión de inventario. Lo que no nos dice es si el proyecto se justifica y si va a guardar o ganar más de lo que costará.

Una justificación es un análisis de los costos versus los beneficios que muestran que los beneficios son mayores y describe exactamente donde se producirán la mejora de los ahorros o ingresos. Muchos están llenos de justificaciones vagas nociones tales como la flexibilidad, servicio al cliente, la integración, el estado de la técnica, la maternidad y otros valores que siguen siendo, indiscutibles e indefinidos. Pero una verdadera justificación tiene dos características necesarias: Se cuantifica, y es tratada como un objetivo o meta.

Las justificaciones son cuantificadas

Una justificación describe los beneficios que se derivarán de hacer un proyecto junto a un análisis costo-beneficio. Debe ser cuantificada, y si no lo es, nadie sabe si en un principio el proyecto vale la pena o en al final si se ha realizado correctamente.
Es necesario considerar la justificación "para incrementar el servicio al cliente." Esto puede ser la reducción de tiempo de respuesta a las consultas de los clientes, la mejora de la exactitud o la cantidad de información disponible, añadiéndolo a los servicios que se ofrecen, o simplemente apoyando a los clientes.

Además, si la justificación está cuantificada, cualquier mejora, por pequeña que sea, en cualquier área que afecta a los clientes, permitirá a la empresa anunciar que el servicio se ha incrementado.

Por ejemplo, si el sistema reduce un promedio de dos minutos el tiempo de espera del cliente a cinco segundos, el servicio ha mejorado, pero son pocas las empresas que dedican los esfuerzos posibles para lograr ese resultado trivial, y, más importante, ningún cliente se dará cuenta.

Las justificaciones se cuantifican sólo cuando se expresan en términos monetarios, los cuales podrían implicar la nómina de ahorro, el aumento de las ventas, o la reducción de los costos en áreas tales como inventarios o finanzas.

Sin embargo, las justificaciones deben ser cuantificadas de manera que puedan ser evaluadas y aprobadas sobre la base de beneficios financieros. Algunos observadores han señalado que no hay otra justificación para cumplir con un requisito legal o mandato.

Por ejemplo, si el legislador impone un nuevo tipo de impuesto en el que se requieren modificaciones a los sistemas con el fin de ponerlo en práctica, las empresas que se ven afectadas no tienen otra opción. Del mismo modo, un departamento del gobierno puede ser necesario para llevar a cabo un proyecto con el fin de cumplir un mandato legislativo. Sin embargo, la justificación última, incluso en proyectos de este tipo, es financiera. Para una empresa privada, el beneficio es el que llega a mantenerse en el negocio, que es económicamente más beneficiosa que la alternativa. Para un departamento del gobierno, mientras que no hay ninguna opción de realizar el proyecto, el factor financiero es determinar la forma de hacerlo más rentable.

Las justificaciones son objetivos, no predicciones

Supongamos que un proyecto se justifica por un esperado aumento de las ventas de 15 por ciento. Cuando el proyecto se está evaluado, nadie puede afirmar con certeza cuál será el aumento, sino que simplemente se dice que es una estimación, sujeta a todas las demás estimaciones. Si esta cifra se realiza o no, depende de si se trata como un objetivo o como una predicción.

Una predicción es una conjetura sobre lo que sucederá, una meta es un objetivo a alcanzar. La diferencia es alarmante puesto que con una predicción, los resultados del proyecto se dejan a la suerte o a lo que el cliente crea. Con un objetivo, la justificación se convierte en una política, prevista dentro del proyecto global. Se convierte en parte de la planeación del sistema, entra en su ámbito, y se convierte en un conjunto de actividades en lugar de un ocio. Su trabajo es asegurarse de que de cumplan las justificaciones que las metas de gestión se acepta la responsabilidad de lograr.

Beneficios intangibles

Las justificaciones de los proyectos por lo general incluyen una larga lista de "beneficios intangibles". El problema es que no existe tal cosa, pues todos los beneficios se realizan en términos de costes o ingresos. Para llamar a un beneficio "intangible" simplemente significa que nadie ha podido adjuntar números a la misma.

Por ejemplo, considerar la flexibilidad, ya que con un sistema flexible, se tiene menos esfuerzo, produciendo beneficios tangibles de los menores costes de mantenimiento y entrega más rápida de las solicitudes de mejora. Además, los departamentos se darán cuenta inmediatamente de los beneficios tangibles que surjan. La flexibilidad es una ventaja debido a que conduce a resultados reales. El problema de qué forma medir los resultados.

Algunos sostienen que, a pesar de ciertos beneficios no pueden cuantificarse, deben aún ser identificados. Es más deberían, ser fijados como objetivos. Por ejemplo:
El sistema será flexible. Se reducirán los costes de mantenimiento un 15 por ciento, con lo que se ahorrarán $ 24.000 por año, y se tiene previsto aumentar la productividad en dos puntos por mes de trabajo, lo que ahorrará un promedio de $100.000 por año en costos de desarrollo en los niveles actuales. El sistema se integrará, para que exista un mayor acceso a la información de los clientes y lograr un 5 por ciento de aumento en ventas, lo que mejorará los ingresos por $ 200,000 por año.

La razón de fijación de objetivos es asegurarse de que habrá un beneficio real, en términos monetarios y los beneficios tangibles se desprenden de la flexibilidad, el estado de la técnica, o el carácter integrado del sistema.

La mejor manera de cuantificar un beneficio intangible es formular tres preguntas: "¿Y qué?", "¿Cuánto?", "¿Qué hará el proyecto en términos monetarios?" Se cuestionan estos aspectos hasta obtener una respuesta con un valor en dólares en el mismo. En última instancia, los administradores del proyecto se verán obligados a dar los números aunque sea con imprecisión, o que no habrá ningún beneficio. He aquí un breve ejemplo:

Cliente: El sistema será flexible.
Project Manager: ¿Y qué?
Cliente: Entonces, vamos a ser capaces de modificarlo con mayor facilidad.
PM: ¿Y qué?
Cliente: Bueno, eso significa que nuestro tiempo de mantenimiento se reducirá.
PM: ¿Cuánto?
Cliente: Eso es difícil de cuantificar.
PM: Haga una conjetura. (¿Cuánto?)
Cliente: Bueno, quizá un 15 por ciento.
PM: ¿Y qué hace que el trabajo a cabo en dólares?
Cliente: Bueno, tenemos tres programadores de mantenimiento de $ 60,000 por año. Eso es $ 180.000 por año total, por lo que probablemente podría ahorrar aproximadamente $ 27,000 cada año.

Se ha cambiado sólo en beneficio de un deseo a un verdadero objetivo. En caso de que un beneficio no sea susceptible de cuantificarse, no es un beneficio y no lleva implícito un objetivo ni pertenece a ninguna lista de justificaciones.

Cuidado con la Justificación fantasma

Si un proyecto se justifica por una reducción del tiempo de proceso de transacciones comerciales, y los números indican que cinco personas tendrán su trabajo reducido en un promedio de una hora al día, en términos de sueldo (además de beneficios) la tasa es de $ 30 por hora con lo que la empresa se ahorrará $ 150 por día, o $ 37,500 por año. Aquí hay tres cosas que pueden ir mal con esta justificación:

Una reducción de cinco horas al día es menos de una persona a tiempo completo, lo que hace difícil para reducir la personal. Es cierto que, debido a la holgura de tiempo como consecuencia, la empresa será capaz de asignar más trabajo a la gente, pero el beneficio proviene de una redistribución del trabajo, no de recortes de personal.

El personal está sobrecargado y tienen que reducir el volumen de trabajo, lo que significa que pueden hacer un trabajo más profundo, que puede conducir a una mejora de la calidad, pero no ahorro en gastos de personal.

Las personas pueden tener conocimientos especializados, lo que significa que no son intercambiables. Nadie se puede cortar, y no hay ningún beneficio real.
El problema con el ahorro de costos es que se trata de un efecto, no un beneficio. Ciertamente, las cinco personas tendrán una hora más, pero esa hora no se traduce automáticamente en beneficios para la empresa.

Un efecto difiere de un beneficio en el sentido de que no implica la reducción de costes o el aumento de los ingresos. Reducir el tiempo del personal necesario para llevar a cabo algunas tareas, ahorra solamente la nómina de sueldos y el beneficio es realmente reducido. Hacer más accesible la información del cliente al personal de ventas, conduce a un aumento de las ventas. La mejora de la calidad es inútil a menos que se incrementan las ventas o se reduzcan los costos de los servicios. Los efectos pueden conducir a beneficios, pero sólo beneficia a constituir justificación de los costos de un proyecto. La mejor forma de eliminar los efectos es hacer preguntas hasta que esté satisfecho de que el "beneficio" es real. Aquí está un ejemplo sencillo:

Cliente: El personal de trabajo se reducirá en cinco horas por día.
Gerente de Proyecto: ¿Para qué?
Cliente: Vamos a ser capaces de reducir nuestros costos.
PM: ¿Cómo?
Cliente: Ah, buena pregunta. No tenemos suficiente de una caja de ahorros a reducir personal.
PM: ¿Qué otra cosa podría hacer con estas personas de su tiempo extra?
Cliente: Bueno, ahora se quejan de que se apresuraron. Más tiempo les permitan hacer un mejor trabajo, que podría reducir revisión. Si pudiéramos reducir sólo 10 por ciento ahorraríamos más de 200.000 dólares por año.
PM: ¿La mejora de la calidad obtener más clientes?
Cliente: Tal vez, pero sé que mejorará la buena voluntad entre los clientes existentes. Hay un beneficio intangible.
PM: ¿Y qué?



En el momento en este diálogo, no sólo se le han ayudado a identificar el cliente que los beneficios reales de el sistema que debe solicitarse, también se han aumentado los beneficios más allá de los que podrían realizarse.

En la revisión de las justificaciones del proyecto, se debe asegurar que los efectos del sistema llevar a beneficios reales que son capaces de realizarse.

Periodo de amortización

Algunas empresas insisten en conocer el periodo de recuperación antes de que se apruebe un gasto. Esta es el período en el que los beneficios recuperan totalmente los costos del proyecto. Los períodos de amortización son fáciles de calcular: hay que dividir los costos del proyecto, incluyendo los gastos de operación, entre los beneficios anuales. Si se ajusta por mes, se tendrá el número de meses necesarios para recuperar los costos del proyecto.

El periodo de recuperación es un poderoso indicador de si proyecto es rentable. Si los costos se pueden recuperar en menos de un año, pocas empresas se niegan a proceder pero si se toman cuatro o cinco años, pocas aprueban el proyecto. La mayoría de las empresas ponen un periodo de recuperación en la propuesta de proyecto de cuáles son los períodos son aceptables y cuáles no.
Cuando se calcula un periodo de amortización, no se calculan los costos futuros para la mayoría de los proyectos, pues el periodo de recuperación es lo suficientemente corto como que la inflación no sea un factor importante.

Componentes de costo

Cuando se revisan los análisis de costo-beneficio, hay que examinar los costos para asegurar que estén completos. Muchos de los proyectos se ha metido en problemas debido a un importante tema, tales como licencias de software o los honorarios de consultoría, que no se incluyen en los costos, pero éstos también deben identificar los gastos de operación durante el periodo de amortización.

Exposición 2.1 se identifica una lista de control que los costes que puede incluir su proyecto y que deberían formar parte del análisis costo-beneficio.

Costos del desarrollo de sistemas

Costos de definición de los sistemas a adquirir.
Costos del diseño del sistema
Costos del diseño de la infraestructura de la red del sistema de costos.
Costos de operación del desarrollo del código, una unidad de prueba, integración y pruebas del sistema.
Costos de la documentación, incluyendo material de entrenamiento.
Costos para gestionar un proyecto, incluyendo funciones de configuración, administración, control de calidad y soporte técnico.

Costos de Hardware

Costos de la definición del alcance, configuración y ordenamiento del hardware.
Capital de costos para adquirir hardware.
Costos de instalación de hardware.
Costos de mantenimiento del hardware.

Costos de Software

Costos de definición de alcance, configuración y ordenamiento del software.
Costos de adquisición de los sistemas operativos y software.
Costos de adquisición de la infraestructura de software como la comunicación, estadísticas de actuación o calidad de la actuación.
Costos de adquisición de soporte de software como administración de bases de datos, interfaces gráficas de usuario y elaboración de reportes específicos.
Costos de instalación y configuración del software.

Costos de ejecución del proyecto.

Costos de viajes y vivienda.
Costos de consulta externa.
Costos de entrenamiento y capacitación.
Costos de proveedores y materiales.

Costos de clientes del proyecto

Costos de operación de la asistencia del personal a cursos de capacitación.
Costos de operación de la participación de los usuarios en los equipos de proyecto del cliente.
Costos de operación de la involucración del cliente en el proyecto.

Costos de implementación

Costos operativos de aumento de personal durante la implementación.
Costos operativos de viajes y vivienda durante la implementación.

Costos de operación de los sistemas

Costos de operación del personal durante el periodo de amortización
Costos de materiales y proveedores durante el periodo de amortización
Mantenimiento de contratos de hardware y software durante el periodo de amortización.
Costos de hardware leasing en el período de amortización.
Costos de actualización de hardware y software en el período de amortización.


Exposición 2.1: Costos potenciales de los componentes.

¿QUÉ PASA SI?

1. El Cliente no identifica los beneficios

Si el cliente no identifica los beneficios, será difícil tomar decisiones que se apeguen a la justificación del proyecto y es más difícil mantener el proyecto en el ámbito de aplicación.

Acciones

Crear una "declaración de prestaciones de trabajo", un conjunto de beneficios que se derivan de la comprensión del proyecto y que parecen razonables. Esta será una declaración de beneficios privados, sino que no tendrá la importancia de una verdadera declaración, pero que permite actuar día a día como si los beneficios son claramente definidos.

Definir el alcance del proyecto en un nivel de detalle mayor de lo normal, y verificar que los mecanismos de cambio estén en su lugar. Esto debería ayudar a superar la dificultad de gestionar un proyecto sin una declaración clara de los beneficios.

2. El cliente se niega a establecer metas u objetivos de beneficios

Si el cliente define las prestaciones pero no las metas establecidas, será difícil de ejecutar el proyecto de tal manera que los beneficios se pueden lograr.

Acciones Calcular el nivel de prestaciones que serían necesarias para justificar el proyecto. Por ejemplo, si el cliente quiere reducir los niveles de inventario, determinar el nivel de las reducciones necesarias para recuperar el costo del proyecto. Si el nivel de beneficios es razonable, proponer a los clientes un conjunto de beneficios, que serán revisados y cuando se ejecute el proyecto. Si no es razonable, por ejemplo, si el cliente tendrá que cortar los niveles de inventario en un 85 por ciento y el cliente todavía quiere continuar, se debe reconocer que es una gestión de un proyecto injustificada.

Si el cálculo de los beneficios es razonable, se debe considerar la posibilidad de aplazar la fijación de los objetivos de beneficio hasta el cliente se familiarice más con el proyecto y así la fijación de objetivos será más fácil.

3. El proyecto se está haciendo para utilizar el presupuesto disponible

En este caso, el proyecto se justifica únicamente por su capacidad para gastar el presupuesto de alguien, no tiene justificación inherente. Sin embargo, esto no significa que no puede ofrecer valor a la organización.

Acciones

En este tipo de proyectos, siempre hay una justificación aparente. Pocas empresas ejecutan abiertamente proyectos sin excusa. Para estos casos se debe actuar en la forma descrita anteriormente para la situación en la que el objetivo del proyecto es real, pero el cliente no identifica los beneficios.

4. El Cliente asume la posición de que la Justificación es un negocio fuera del mandato del administrador del proyecto.

La consecuencia más evidente es que no tenga una justificación para trabajar con en el proyecto. Sin embargo, hay una cuestión más grave: su rol. Con el fin de gestionar el proyecto, tendrán que ser activamente relacionadas con aspectos del negocio, no sólo desde el punto de vista de la funcionalidad, sino en términos de contexto dentro de la organización del cliente. Si se bloquea o limita al alcance del proyecto, la capacidad de entregar valor real se verá seriamente comprometida.

Acciones

Intentar hacer comprender al cliente del rol del administrador. En particular, señalar que su trabajo es entregar valor a la organización y que ese trabajo es más que un calendario de reunión. Informar a su cliente el por qué es necesario comprender la justificación. Describir el papel en la gestión del alcance y la toma de decisiones.
Si estos intentos fallan, es necesario dejar claro que esta actitud del cliente lo queestá obstaculizando la capacidad para tener éxito.

¿POR QUÉ CONSIDERAR LA JUSTIFICACIÓN DEL PROYECTO?

Algunos directores de proyecto argumentan que la justificación no es de su preocupación, que una vez que un proyecto ha sido aprobado su trabajo es simplemente obtener resultados. Sin embargo, la obtención de resultados significa garantizar que el cliente disfruta de los beneficios utilizados para justificar el proyecto. También significa ser capaz de defender el proyecto contra recortes y los números de reevaluación del alcance o cambio en los costos.

Asegurar que los beneficios se cumplan

La planificación del proyecto incluye la creación de planes de ejecución, que normalmente consisten en la realización de pruebas, entrega, y eliminación gradual de los sistemas existentes. Sin embargo, para realmente obtener resultados, la aplicación plan debe también describir en detalle cómo el cliente se dará cuenta de los beneficios descritos en la justificación del proyecto.
Por ejemplo, si el proyecto se justifica por la capacidad de reducir el inventario en un 15 por ciento, ¿Con qué rapidez se reducirá? ¿Qué temas se redujo primero? ¿En cuánto? ¿Cómo participarán los proveedores? ¿Cuál es el papel del sistema en la toma de decisiones sobre la reducción de inventario? ¿Qué medidas son necesarias para garantizar que el servicio al cliente no se pondrá en peligro? El plan de ejecución debe responder a estas preguntas para todos los objetivos que se fijaron en la justificación del proyecto. Si no se entiende la justificación, no se puede planificar la forma en que el cliente se dé cuenta de los beneficios.

La defensa contra recortes

Con frecuencia, los nuevos ejecutivos convierten a la reducción de costos en un desafío de un proyecto en curso. Si la justificación original estaba bien preparada y es razonable y en realidad justifica el proyecto, será fácil de defender. El director del proyecto que considera que no es el encargado de realizar la justificación, terminará sin armas para defenderse contra la reducción de presupuestos, y el proyecto es poco probable que sobreviva.

Reevaluación del proyecto
Los costos, beneficios y el alcance de un proyecto cambian: Los costos por lo general suben, los beneficios suelen ir hacia abajo, y el alcance crece normalmente. En algún momento, los costos pueden crecer hasta superar los beneficios. Una de las responsabilidades para la identificación de este punto, es informar al cliente cuando las condiciones ya no justifiquen la continuación del procedimiento. Sin una buena justificación, esta tarea es imposible y el proyecto utilizará demasiados recursos, esfuerzo, y tiempo.

Cambios de la evaluación del alcance.
Cuando una justificación del proyecto está bien definida, se pueden aplicar a las solicitudes de cambios de alcance.

Por ejemplo: Durante el análisis de un proyecto de desarrollo de ventas, los usuarios solicitan un cambio a las pantallas que tendrá un costo de $ 10.000. En caso de que el cambio se haga, si el proyecto se justifica por el aumento de los ingresos procedentes de ventas la cuestión se convierte en ¿Cómo y por cuánto este cambio de pantalla contribuirá a un aumento de ingresos por ventas? Si es por más de $ 10.000, el cambio de alcance está justificado. Pero si la justificación era producir un " Sistema de análisis del estado de la técnica de ventas", ¿quién puede decir si los cambios a las pantallas mejorarán la técnica?.

El establecimiento de actitudes del Cliente
Una de las razones que las personas se resisten a establecer objetivos es el sentimiento negativo que viene con el fallo de ellos. Mientras más incierto el destino, menor sufrimiento. Como un director de proyecto, ¿cómo se puede proteger contra las consecuencias de no realizar un beneficio?

Es fundamental entender que su responsabilidad no es para entregar beneficios, pero sí de asegurarse de que han sido definidos y que el trabajo producido se puede utilizar para alcanzarlos.

Por ejemplo, si un proyecto se justifica por una disminución del 15 por ciento dirigidas a los niveles de inventario, es su trabajo para producir un sistema que otros pueden usar para reducir existencias. También es trabajo del director de proyectos, como parte de la planificación de la ejecución, trabajar con los directores responsables, en este caso el administrador de inventario a la forma en que el plan de beneficios se hará realidad. Sin embargo, no es su trabajo tomar decisiones de almacenamiento o eliminar los productos. Esa es la función del gestor de inventario.

Al discutir los beneficios con los clientes, se debe dejar claro que aunque se les ayudará a planificar, la realización de estos beneficios depende de ellos y que a menos que estén dispuestos a hacer del director de proyectos el gerente de inventario (o de los recursos humanos o de marketing o de operaciones o de cualquier área de su proyecto direcciones), no puede ser responsable de los resultados. Su función es doble: asegurarse de que existe un beneficio y producir un producto que se pueden utilizar para realizar dicha prestación.

¿QUÉ PASA SI?

1. El cliente no quiere gastar los recursos preparando un plan de cumplimiento de beneficios.
Si el cliente no tiene prevista la forma de darse cuenta de los beneficios, no se harán realidad y el proyecto será en vano.

Acciones

Averiguar las preocupaciones del cliente. Normalmente serán ya sea financieras, de organización, o basado en los programas y tiempos.Si el cliente se refiere a la organización, se le debe pedir que indique a un encargado de preparar el plan. Si el cliente son las preocupaciones financieras o de horario, es necesario preparar un conjunto de argumentos para demostrar que la planificación de los beneficios no es irrelevante, sino que es fundamental para el proyecto. Se debe revisar también la lista de personas involucradas en el proyecto y elegir a un ejecutivo de un puesto de alto nivel que haya manifestado un gran interés en los beneficios exponerle los aumentos. Consultar con el comité directivo y el ejecutivo patrocinador y presentar los argumentos a los mismos. Si ninguna de estas acciones son eficaces, hay que dar a conocer al cliente, que el proyecto no es independendiente de los beneficios utilizados para justificarlo y recomendar que el proyecto se termine, ya que no aportará el valor exigido.

2. El proyecto evoluciona hasta el punto de que los beneficios ya no compensan los costos
Si la justificación del proyecto ya no aplica porque los costos han aumentado y los beneficios han desaparecido, continuar con el proyecto sería un desperdicio de tiempo y dinero del cliente, así como desvío de valiosos recursos de personal en una pérdida de esfuerzo.

Acciones

Revise el análisis costo-beneficio para tratar de encontrar algunos beneficios adicionales o para aumentar los ya previstos. Esto puede sonar como esquivar los números, pero los nuevos beneficios suelen surgir durante un proyecto. Si la revisión de los números son favorables al proyecto, se debe informar al cliente y continuar. Si no es así, el proyecto ya no está justificado, y se debe tratar de convencer al cliente para poner fin al proyecto. Revisar el análisis de costo-beneficio para reflejar la posición actual, para indicar la pérdida a la empresa si el proyecto se dobla en este momento y si se lleva a término. Incluyendo cualquier valor del trabajo actual que reducirán la pérdida. Determinar donde se asignará al equipo del proyecto si cambia y tratar de poner un valor en este trabajo. Aquí están tratando de señalar el lado positivo de poner fin al proyecto. No se debe que permitir al cliente a tomar la posición de que el proyecto ha fracasado, explicando que los cambios en las condiciones han hecho prudente retroceder antes de que termine con los recursos y la carrera profesional y se convierta en un fracaso.

¿CUÁL ES EL CONTEXTO DE ESTE PROYECTO?

Gestores de proyectos no suelen participar en el inicio de un proyecto. En el momento en que aparecen en la escena, por lo general ya ha adquirido su propia historia y su impulso. Para entenderlo, es necesario responder a las siguientes seis preguntas:

¿Cuáles fueron las condiciones comerciales que condujeron a alguien para proponer el proyecto en el primer lugar?
¿Cómo fue el proyecto presentado a la gestión, y cómo se evalúa y aprueba?
¿Cuáles son las alternativas al proyecto que el cliente considera?
¿Cuáles fueron (y son) los argumentos contra el proyecto?
¿Cuál es la visibilidad del proyecto en la empresa cliente o departamento? ¿Qué tan importante es visto?
¿Cuáles son las actitudes hacia el proyecto? En concreto: ¿Es acogido como deseable, aceptado como necesario, o condenado como mal? ¿Es considerado como fácil, difícil, o imposible? ¿Es visto con entusiasmo, renuncia, o temor?

Con las respuestas a estas preguntas, se puede vender el proyecto a los usuarios y para crear una expectativa positiva para él, crear una atmósfera para facilitar la cooperación a fin de resolver los problemas y para ayudar al cliente a alcanzar los beneficios esperados. Sin responder a estas preguntas, el administrador no puede influir, y mucho menos imponer la dirección del proyecto.

Malas Actitudes
Una de las consecuencias de preguntar sobre los antecedentes del proyecto es que es posible descubrir cosas que son preferibles no saber. Por ejemplo, se puede descubrir que algunas personas que apoyan el proyecto, no creen que tendrá éxito, y que para muchos su fracaso en general se consideraría como una señal de que todo es correcto con el mundo.

En primer lugar, es necesario determinar si esa actitud se merece, si este proyecto es realmente una mala idea, o es una lucha de poder entre las facciones. Desde un punto de vista neutral, que puede definir si el proyecto es una mala idea, debe ser injustificado o inviable. Si, después de un examen la conclusión es que el proyecto es inviable o injustificado, entonces el gestor de proyectos es el responsable de señalar al cliente que los detractores son correctos y que el proyecto no debe o no se puede realizar. Si el cliente insiste en el procedimiento, entonces se enfrentan a la gestión, ya sea de un proyecto injustificado o que probablemente no puede prosperar por razones técnicas.

Si, por otra parte, el proyecto está justificado y es viable, entonces la oposición es la misma organización y es necesario averiguar por qué.
La gente normalmente se opone a un nuevo sistema porque:

Lo ven como derivados de las necesidades de otro departamento sin hacer referencia a ellos.
Lo ven como imposición.
Tendrán que cambiar los hábitos de trabajo cómodo.
Se sospecha que se trata de una estratagema para alterar el equilibrio de las relaciones laborales.
Se sospecha que no va a trabajar y que su fracaso se atribuye a ellos.
Reconocen que en el desarrollo y la aplicación será necesario un esfuerzo adicional no deseado de los mismos.
Sospechan que se traducirá en despidos.

¿Qué puede hacer para superar este tipo de actitudes?
En primer lugar, pedir que sean de su interés. Si la oposición al proyecto proviene de personas que no son de cualquiera de los miembros del equipo del proyecto o el equipo cliente y entonces es una situación relacionada con la implementación, cuestión que pertenece a los operadores del sistema. No es responsabilidad del administrador de proyectos la gestión de relaciones corporativas. Al preparar el plan de aplicación, se debe insistir en que estas actitudes se han reconocido y que es necesario desarrollar planes para tratar con ellos, pero no se puede permitir que se inmiscuyan en la realización del propio proyecto.

Por otra parte, la oposición es en gran medida de responsabilidad del administrador si las personas que se oponen a la proyecto son parte de ella. Un caso extremo se produce cuando algunas de las personas creen que con el éxito del proyecto perderán sus puestos de trabajo. En tales casos, la solución de sus actitudes negativas es una de las mayores preocupaciones. ¿Cómo hacer frente a este problema es la situación, pero aquí hay algunas sugerencias:
Evaluar si la oposición es razonable. Por ejemplo, los temores de los despidos son razonables; ira hacia otro departamento no lo es.

Si la conclusión de que la oposición no es razonable, hay que plantear la opinión de llevar a cabo un exitoso proyecto claro para todos y es posible que se tengan que tener conversaciones con algunos de los miembros del equipo, y, en casos extremos, puede que sea necesario para sustituir a los que sean escépticos. El objetivo es crear una cohesión del equipo a pesar de las actitudes.

Si la oposición es razonable, se tiene que hacer todo lo necesario para mitigar el problema que lo crea. Por ejemplo, si la gente será despedida cuando el proyecto esté terminado, pedir al cliente desarrollar un plan de transición para ayudarles a encontrar nuevos puestos de trabajo. Su motivación no es la compasión, sino reconocimiento de que a menos que se resuelva el problema, su proyecto estará lleno de baja moral, poca cooperación y la confrontación. Por supuesto, el punto importante es que, a menos que se tome el tiempo para explorar el fondo del proyecto, las malas actitudes no puede tomar ninguna acción para crear un proyecto exitoso ni una experiencia positiva para todos sus participantes.

¿QUÉ PASA SI?

Esta desalentado de "perder el tiempo" en los antecedentes

Si no se entienden los antecedentes, se es vulnerable ante los críticos del proyecto y se arriesga a tener malentendidos que no sólo ponen en peligro el proyecto sino la capacidad para dirigirlo.

Acciones

Organizar reuniones por separado con dos o tres personas que han participado desde el principio. Preguntando casualmente para que no se considere ser tan molesto como una entrevista y formular preguntas que se refieran a incidentes específicos o de las personas.
Si se encuentra con una cuestión de fondo que podría obstaculizar seriamente el proyecto, se plantean con el cliente en dos contextos: como una cuestión que debe resolverse, y como un ejemplo de los problemas que pueden producirse cuando se disuade de realizar su trabajo.

Obtiene información de conflictos

Si en el antecedente se obtiene información no coherente, se tiene un rumor y el riesgo es que hacen inadecuadas las decisiones.

Acciones
El tratamiento de la incoherencia como una valiosa fuente de información y enfocar el objeto de la incoherencia.

El proyecto es objeto de una lucha de poder o rivalidad interdepartamental

Si dos o más servicios de dictámenes de su proyecto, el propósito, alcance, o justificación parecen muy difíciles de gestionar y no importa lo que se haga, hay oponentes.

Acciones
Identificar al cliente y los administradores de departamento. Esto puede parecer simple, pero en muchos proyectos, las líneas de responsabilidad son difusas. Hay que identificar a un solo cliente: el gerente del proyecto y que será responsable de todas las decisiones.
Si en el proyecto no está clara la propiedad, se debe insistir que la organización del cliente elija a un propietario del proyecto y si el cliente no selecciona un propietario claro, se puede elegir uno y dejar claro a la organización del cliente que debe tener un solo cliente departamento e identificar qué departamento se eligió y por qué.

Si el cliente ha nombrado un director de proyecto o un comité de dirección hacia un departamento, su elección es clara y en conversaciones posteriores, cuando los miembros de otro departamento intenten tomar decisiones o acciones específicas, simplemente se debe decir que están dispuestos a asumir la solicitud del departamento, pero que no se puede cumplir sin la aprobación del cliente.

¿QUIÉNES SON LOS PARTICIPANTES?

"Esto sería un gran proyecto," se lamentan a menudo, "si no fuera por los usuarios." O, "Las políticas de este proyecto son el asesinato. " El personal del proyecto anhela el proyecto en que los usuarios están conformes, las recomendaciones técnicas norman, y la "política" no existe.

Política vs Sociología
Hay una diferencia entre la política y la sociología. "Política" se refiere a la astucia, doble juego, dos caras, pues ese comportamiento normalmente implica la palabra. "Sociología" se refiere a la normalidad, honestidad, firme cuando surgen diferencias de opinión. Pocos proyectos tienen política, pero todos tienen la sociología.

Para ver una situación de conflicto o desagrado como política, es atribuir mala fe a la gente involucrada: Los autores ponen en peligro el proyecto para obtener beneficios personales. Sin embargo, para interpretar la misma situación como sociológica, es reconocer que diferentes personas pueden llegar a conclusiones diferentes, pero comparten objetivos y preocupaciones. Evidentemente, el segundo punto de vista es más probable que lleve a la discusión, aclaración, negociación y resolución. Siempre en un proyecto alguien pronuncia la palabra política, la repetición de la declaración en lugar utilizando la sociología. No hay manera más segura de prevenir el endurecimiento de las actitudes.

Sin embargo, la política, en su forma más cruel, no existe. La segunda mejor defensa en contra de ella es documentar todo, obtener las firmas de todas las decisiones, llevar un diario de eventos del proyecto, registrar todas las llamadas y faxes que se realicen y actuar como un abogado se enfrenta oposición hostil.
La mejor defensa es el de encontrar otro proyecto.

La identificación de los jugadores

Para llevar a los participantes en un proyecto de manera eficaz, se debe comprender quiénes son y cuáles son las actitudes hacia el proyecto. En concreto: ¿Quiénes son los campeones de proyectos, los que han apoyado el proyecto desde el principio y se entusiasmados con la conclusión de su servicio? ¿Por qué son entusiastas? ¿Quiénes son los detractores del proyecto, los que han luchado en contra o en contra del proyecto? ¿Por qué se oponían? ¿Quiénes son los que no tienen fuertes convicciones y se puede acarrear a aceptar cualquier forma? ¿Qué los acarrea? ¿Quién parece que ganará si el proyecto tiene éxito? ¿Quién va a ganar realmente? ¿Quién parece que perderá si el proyecto tiene éxito? ¿Quién pierde realmente?

El patrocinador ejecutivo
El patrocinador ejecutivo es miembro de la dirección que está comprometida con el proyecto y que tiene la función primordial: decidir a un comité de gestión o la junta de directores y tiene la autoridad para decir "Quita tus manos de mi proyecto". El promotor no está implicado en los detalles y puede ser incluso invisible para el equipo del proyecto, pero cualquier proyecto que no tiene un patrocinador está en riesgo.
La segunda función del patrocinador ejecutivo de se produce al final del proyecto, cuando los usuarios tienen pérdidas, retrasos, y frustran todos los intentos de aplicar el nuevo sistema, el promotor tiene la autoridad para garantizar el cumplimiento, si no se puede la cooperación.
Se debe averiguar quién es el patrocinador ejecutivo y proporcionar informes de situación. El cual, apreciará la información y estará en una mejor posición para luchar por el proyecto si es necesario.

El Comité Directivo
El comité directivo del proyecto, que debe consistir de los altos de gestión de clientes, no es un foro de resolución de problemas o un lugar para una discusión de cuestiones de detalle. Su trabajo es hacer cumplir, desde el punto de vista del cliente, los términos de referencia del proyecto de. El comité directivo también debe aprobar o negar las solicitudes de los recursos o los cambios en el alcance o el calendario.

Un comité directivo se convierte en una molestia cuando se insiste en hablar de las cuestiones rutinarias. Si los debates, por ejemplo, si el código de identificación debe ser quince o dieciséis dígitos, ya no es una dirección comité, se trata de un grupo de usuarios. El problema es que el verdadero grupo de usuarios dudan en tomar decisiones porque temen que sus miembros van a ser anulados por sus jefes en el comité directivo, y se adormecerá el proyecto.

Para permitir al comité directivo a centrarse en su trabajo, tomar el control de las reuniones, que debería ser mensual, es necesario preparar el orden del día, guía de los debates, y cualquier intento de desviar discutir los detalles. Esto no significa que los miembros del comité de dirección son variables ficticias que no tienen conocimientos especiales que ayudaría al proyecto. El reverso es, sin duda, cierto, y los que quieren participar en una exposición más detallada deben poder hacerlo, pero mantener las funciones por separado. Los miembros del comité de dirección, actuando como miembros del comité de dirección, deberían estar preocupados con los detalles.

El Grupo de Usuarios
El grupo de usuarios es el conjunto de personas que serán responsables de los detalles de día a día y las decisiones en el proyecto. En el mejor de los grupos de usuarios, una persona tiene la autoridad para tomar decisiones y la voluntad de hacer oponerse. En el peor de los casos, la "democracia" prevalece y nadie está dispuesto a tomar una decisión. Se calendariza mucho tiempo para las reuniones. Independientemente del tipo de grupo de usuarios, cuando se necesita una decisión, hay que documentar con claridad los temas y alternativas. Distribuir la documentación antes de la reunión, y garantizar que nadie salga de la habitación hasta que se alcance una solución.

El Gerente de Proyecto Cliente
El cliente es un director de proyecto de los principales miembros del grupo de usuarios del cliente y es el principal contacto entre el administrador del proyecto y la organización del cliente. El gerente del proyecto del cliente debe tener la autoridad para aprobar los resultados o para resolver los problemas. Este papel es fundamental, por lo que se debe asegurar que se ocupe formalmente.

¿QUÉ PASA SI?

El Cliente no designa un patrocinador ejecutivo o designa a uno que no sea superior

El proyecto tendrá nadie velando por los niveles superiores, lo que significa que van a ser vulnerables a los costos de corte o de un cambio de prioridades y será difícil competir con otros proyectos por los escasos recursos.
Acciones Prevenir esto. Cuando se solicita un ejecutivo patrocinador al inicio del proyecto, hay que determinar la antigüedad que este requiere. Esto hace más fácil objetar cuando el cliente se propone un centro gestor.

El Cliente no nombra un Comité Directivo

Las decisiones importantes, en particular las que afectan a cuestiones tales como el presupuesto, los recursos, o el alcance del proyecto, serán casi imposibles de conseguir. El administrador del proyecto pasará una gran cantidad de tiempo de gerente en gerente oyendo comentarios tales como "Tu recomendación suena bien para mí, pero no tengo la autoridad que lo apruebe por mí mismo. "

Acciones Identificar un grupo de representantes del cliente a que se piensa que debería estar en el comité de dirección y, a continuación, llamar a una reunión para discutir una serie de cuestiones donde se necesita a todos los presentes. Después de la reunión, el estado de su intención de reunirlos de nuevo cuando surgen problemas en el futuro. Esta es la creación de un comité directivo informal, que nunca serán llamados, pero que tendrá la autoridad colectiva para tomar las decisiones que se necesitan.

El Cliente no nombra un director de proyecto de clientes

No habrá una sola persona a quien se le pueda informar o con el que se pueden discutir cuestiones. Además, todos los trabajos detallados del cliente, como la organización de reuniones, la distribución de resultados de revisión, o navegación a través de la organización cliente, caerá sobre los hombros del administrador del proyecto.

Acciones

Señalar que esta es una posición crítica y que si se deja sin cubrir, habrá riesgos importantes y esfuerzo extra impuesto en el proyecto. En la estimación, añadir el tiempo y los costos para la gestión de proyectos del cliente. Informar al cliente que si se tienen que aceptar estas responsabilidades, los costos y el calendario se verán afectados. Si son externos a la organización del cliente, también se puede señalar que uno de su pueblo puede hacer el trabajo más eficientemente que usted.

El Comité Directivo Insiste en anular las decisiones del Grupo de Usuarios

Las reuniones del comité de dirección será largo, con frecuencia, ásperas y por el nivel de detalle del negocio y el verdadero grupo de usuarios poco a poco irá retirándose del proyecto.

Acciones

Tener un control más estricto de la agenda de la reunión, que debería limitarse a la situación de los proyectos y cuestiones en términos de referencias. Impugnar cualquier digresión en detalles del negocio como fuera del ámbito de la reunión. Precaución: Esto no va a disuadir a todos.

Evitar pedir más detalles orientados a los miembros del comité de dirección para unirse al grupo usuario. En primer lugar, probablemente porque están ocupados. En segundo lugar, si se acepta, la dinámica del grupo de usuarios será alterada por la presencia de uno o varios jefes.

Suponiendo que se ha establecido claramente la forma en que el proyecto se llevará a cabo, la interferencia del comité directivo será una salida de que se aprobó la estructura. Enfocar al comité a una solicitud de cambio de alcance basada en el esfuerzo necesario para dar cabida a su participación. Tomar medidas adicionales para la participación de grupo de usuarios. Asegurarse de que se copian en todos los apuntes que se ocupan con detalles, y adelante todos las decisiones del comité de dirección. Si alguna vez se implican a través de su comportamiento o comentarios que son ajenos al proyecto, no se debe perder ningún entusiasmo por el proyecto a nivel de trabajo.

Considera abusivos o arrogantes a los representantes del cliente.
No sólo tener que tratar con estas personas hacen la vida desagradable, pero el proyecto sufrirá porque se tiende a evitarlos, lo que afecta la calidad de la información o las decisiones de las que son responsables.

Acciones

Reconocer que nadie está obligado a tolerar la conducta abusiva, incluso de altos clientes. Si las actitudes abusivas son la norma para la organización del cliente, no hay capacidad de encontrar ningún alivio. Se puede mantener la relación o salir del proyecto, asegurándose de que todo el mundo entienda las razones. Si el abuso se limita a una o dos personas, se pueden adoptar medidas enérgicas para poner fin al mismo y en una empresa privada o pequeños grupos de conversación, cuando el abuso ocurre, se informa a la persona que no son ni necesarios ni están dispuestos a tomar el abuso y que el debate ha terminado.

¿CUÁLES SON LAS PRIORIDADES DEL CLIENTE?

Cualquier cliente razonable lo quiere todo: en el tiempo, sobre el presupuesto, y en pleno funcionamiento. Nadie quiere iniciar un proyecto con la actitud que uno de estos tendrá que ir, pero hay momentos en que reunir todos ellos es imposible y es prudente saber de antemano lo que puede ser sacrificado.

Muchos clientes reconocen que el sistema de construcción es difícil y arriesgado. Al señalar esas prioridades, no están permitiendo deslizarse, sino dan instrucciones para la gestión.

Si el cliente no es voluntario de las prioridades, hay que entender la comprensión de los antecedentes y justificación del proyecto. ¿Cuáles son las consecuencias de los desaparecidos el calendario? ¿Qué pasa si se excede el presupuesto? ¿Cuál es el impacto si el sistema no está completo? Si se entienden estas prioridades, cuando el proyecto tiene dificultades, habrá mejores condiciones de recomendar medidas que el cliente puede aceptar. Una advertencia importante es no preguntar al cliente directamente para estas prioridades.

¿QUÉ PASA SI?

Obtiene diferentes prioridades de los diferentes grupos de clientes
Se van a encontrar dificultades para establecer prioridades dentro del proyecto, incluso si está en condiciones de cumplir el plan. Además, esta debe ser una señal de peligro para que su proyecto se convierta en un objeto de controversia enla organización cliente.

Acciones
Este es un ejemplo de un conflicto dentro de la organización cliente sobre el que tiene la propiedad del proyecto. Discutir la contradicción con el cliente o el gerente del proyecto y cada uno de los miembros del comité de dirección. Se puede obtener del cliente información sobre la organización que le ayudará a gestionar el proyecto. Si el día llega cuando se tiene que informar de que, por ejemplo, el presupuesto está en peligro, discutir el problema en privado con los que lo consideran fijos. En general, evitar anunciar este tipo de problemas en una reunión donde las personas no han tenido la oportunidad de evaluarlo.

INICIO DEL PROYECTO

Los proyectos son costosos, lo cual es la razón por la organización no debería iniciarse sin una garantía de que proporcionarán un valor. Sin embargo, en muchas organizaciones, hay proyectos que parecen surgir de alguna manera. Nadie está seguro de cómo se inició, y nadie sabe si están justificados o incluso de los esfuerzos que se requieren.

A menudo, un proyecto aparecerá cuando un ejecutivo de alto nivel de cooperación técnica solicita una persona para "echar un vistazo a esto para mí. "El alcance de la solicitud luego se expande, aprovechando el personal técnico de otros, hasta que su demanda de recursos comienza a interferir con otros proyectos. La solicitud se ha convertido en un proyecto encubierto, que es un problema para las cinco razones:

1. No existe ninguna evaluación para determinar cuánto esfuerzo se requiere, por lo tanto no la capacidad de planificar despliegue de recursos.

2. No existe ninguna evaluación para determinar si el proyecto apoya o se resta de la dirección estratégica de la organización.

3. No existe una definición clara del ámbito de aplicación, por lo tanto, ningún mecanismo para limitar el esfuerzo.

4. No hay ningún análisis de beneficios, por lo tanto, ninguna posibilidad de garantizar que el proyecto proporcionará valor a la organización.

5. Los proyectos regulares donde las personas han sido extraídas de sus horarios de y superado los presupuestos, aumentan los costos y retrasan la realización de beneficios.

El propósito de la iniciación del proyecto es asegurar que cada proyecto pasa a través de un proceso de evaluación, diseñado para determinar si el proyecto se debe hacer, el esfuerzo aproximado que necesitan, y cuáles son sus prioridades relativas a los otros proyectos. Un proceso de iniciación del proyecto se describe en las Herramientas de Gestión del Proyecto.
Para un director de proyecto, no es responsabilidad establecer un proceso de iniciación del proyecto: que es el trabajo de de gestión o de un proyecto de gestión de oficina. Sin embargo, tiene otras dos funciones. La primera es asegurar que para cualquier proyecto se pide que la gestión ha pasado por algún tipo de evaluación para garantizar tres cosas:

1. Que apoya la orientación estratégica de la organización
2. Que tiene una clara declaración de alcance
3. Que se tiene una clara declaración de beneficios

Durante la etapa de iniciación, la declaración de beneficios no es un análisis costo-beneficio, ya que todavía no saben la cuantía de los costos. Es una declaración de los tipos de beneficios que el cliente espera que el proyecto ofrezca. Su segunda responsabilidad es estar atentos a cualquier intento de tirar de su gente en otras tareas. Si otro proyecto necesita algo de esfuerzo por parte de uno o más miembros de su equipo, tendrá que negociar con el gerente del proyecto, manteniendo un equilibrio entre su deseo de proteger sus recursos con los intereses generales de la organización. Sin embargo, el verdadero problema que se desea evitar es que el equipo sea arrastrado fuera a hacer algún trabajo sobre un "proyecto" que oficialmente no existe.
Antes de que se pueda tomar cualquier acción, se debe primero determinar que hay un problema. En muchas organizaciones, los altos ejecutivos habitualmente se enfocan en el personal técnico, de los que han llegado a depender, para hacer algún trabajo para ellos. Hay que dejar claro al equipo que el administrador del proyecto debe aprobar las solicitudes de esa clase. O bien el miembro del equipo debe informarle de la solicitud antes de que tome ninguna acción al respecto. Si el proyecto puede permitir la ausencia del miembro del equipo por unos días, se podrá decidir la concesión de la solicitud, pero asegurándose de que el solicitante conoce la aprobación, si no puede darse el lujo de perder el miembro del equipo, incluso por uno o dos días y se tendrá que rechazar la solicitud.

Esto no es una posición cómoda. Puede parecer burocrático al denegar una solicitud sobre la base de que no ha pasado por un proceso de iniciación formal. Tal vez lo más problemático es que ello puede ser una carrera de limitación de movimiento. Antes de tomar una posición tan fuerte, que necesita para estar seguro de que se tiene el apoyo de la gestión directa. Si no, no se tiene ninguna copia de seguridad y defensa en contra de un alto directivo de la inasistencia en que cumpla.

Sin embargo, si no es rechazada la solicitud, el proyecto estará en peligro cuando el equipo ya no sea miembro disponible. La estrategia es reconocer que si el proyecto sufre, también lo hace la organización y los beneficios que se esperaba.

Se necesita hacer una reunión con el director que hizo la petición y señalar la importancia del miembro del equipo en el proyecto y qué ocurrirá con su calendario y el presupuesto si éste se fuera, incluso durante unos días. Es útil si se puede sugerir una alternativa, que puede ser el préstamo de un miembro del equipo durante un período limitado, la utilización de otro miembro del personal, o una sugerencia de que la petición se aplace hasta un momento crítico en el proyecto. También puede considerar la información de los patrocinadores y pedir su ayuda en la protección del equipo. Por último, si todas estas medidas fracasan, realizar un documento con el efecto de la ausencia del miembro del equipo, de modo que cuando se le preguntó por qué el proyecto resbaló, se tenga una respuesta formal.

Exposición 2.2: Lista de comprobación para la Comprensión del Proyecto

¿Entiende usted los costos del proyecto y los beneficios?
¿Están cuantificadas las justificaciones del proyecto?
¿El cliente acepta la justificación de proyectos como objetivos? ¿Tiene una clara comprensión de los antecedentes del proyecto? ¿Se puede clasificar cada uno de los participantes en términos de su apoyo u oposición al proyecto?
¿Ha encontrado el patrocinador ejecutivo? ¿Existe un comité de dirección? En caso afirmativo, ¿ha establecido que fijará el orden del día de las reuniones?
¿Ha escrito su comprensión del proyecto, justificación, antecedentes y personas?
¿El proyecto se ha iniciado correctamente?

Gep2009 Eq9 Lec Hallows Cap1 Y 2 Presentacion

View more href="http://www.slideshare.net/">presentations from AralisPG.