1. Gestión de proyectos de sistemas de información Espejo Hernández Omar Antonio. Gestión y Evaluación de proyectos. Dr. Carlos Alberto Torres Gastelú

2. En el capítulo 1, "Introducción", "El papel de una Oficina de Gestión de Proyectos" se refiere a un nuevo componente de la gestión del proyecto y cómo se puede promover la disciplina de gestión de proyectos. La sección "Gestión y Participación" se describe cómo evitar las trampas en la gestión de los proyectos cuando no son sólo el director del proyecto, sino también un equipo participante. Esta sección también se ocupa de las cuestiones en la gestión de múltiples proyectos. Capítulo 2, "Comprensión del proyecto," . "La iniciación del proyecto." Conseguir un proyecto iniciado correctamente es una de las claves para gestionar correctamente, y esta sección se describe lo que un buen proyecto debe implicar proceso de iniciación.

3. Capitulo 1:introducción

4. Descripción general Felicidades. Se le ha dado su propio proyecto a ejecutar. Si usted es como la mayoría de los directores de proyectos, que es parte de eufórica que su empresa le ha confiado una importante misión, mientras que el resto de ustedes está petrificado que pronto descubrirá la magnitud de su error. Si el proyecto es el primero y se le está "probando", o que ha estado haciendo esto por años, pero nunca en un proyecto de este tamaño, este libro está diseñado para usted. Espero que te sean útiles. Su contexto y las limitaciones son diferentes de los de la línea de gestión, pero su preocupación es la misma: dirigir un grupo de personas para lograr un objetivo. Por lo tanto, los administradores de proyectos necesitan saber cómo manejar presupuestos, personas y procesos.

5. EL CONTEXTO DE LA GESTIÓN DE PROYECTOS Existen cinco características hacen único el contexto de la gestión de proyectos: La responsabilidad sin autoridad Su fuente de energía Transitoriedad del Proyecto La observación de que usted obtenga lo que quiere conseguir La necesidad de herramientas y técnicas especializadas.

6. RESPONSABILIDAD SIN AUTORIDAD Como un director de proyecto, usted es responsable de un proyecto. Si no cumple con su presupuesto, el calendario, o las expectativas, que son los que tendrán que rendir cuentas y que, como mínimo, sufrirá la presión de la gestión y recibirá una evaluación de la actuación profesional desfavorable. Llevar el objetivo en un proyecto requiere de recursos: las personas, equipos y servicios de apoyo. Sin embargo, con raras excepciones, los directores de proyectos no comandan sus recursos. Usted no puede asignar arbitrariamente al personal a sus proyectos, la adquisición de equipo como lo necesite, contratar a personas, o el lugar a sus necesidades en la parte superior de la lista de prioridades empresariales. Usted no puede promover o degradar incluso personal. Esas prerrogativas pertenecen a los supervisores y los directivos.

7. LA FUENTE DE PODER El director del proyecto, a pesar de la falta de autoridad formal, lleva consigo una posición de poder considerable para los gestores de proyectos que estén dispuestos a ejercerla. La fuente de poder es la realidad que el director del proyecto es el único capaz de ofrecer valor al proyecto, sin un director de proyecto, el proyecto se encuentra en peligro extremo. El ejercicio de este poder es el que el gerente del proyecto está dispuesto a retirarse de un proyecto en condiciones extremas. Hablando claro, usted tiene el derecho y la obligación, para decir a un cliente o para su gestión, "Este proyecto no puede tener éxito en estas condiciones, y hasta que cambie, no voy a continuar."

8. TRANSITORIEDAD DE PROYECTO. Los equipos ejecutan proyectos los proyectos no los directivos. Una de sus principales tareas es la creación de equipos. También es el caso de la línea de gestión, pero la diferencia es que mientras perduren los departamentos, los proyectos son de carácter temporal. Usted debe solicitar la creación de equipos un grupo de personas con habilidades que pueden no tener compromiso con el proyecto.

9. 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 la finalización se estima en gran medida desconocida fuera de la disciplina. Técnicas, tales como diagramas de Gantt o análisis del camino crítico, se han convertido en algo común en los negocios y se utilizan en general la práctica empresarial como en la gestión de los proyectos oficiales. Además, es necesario que las mismas herramientas y técnicas sean utilizadas por todos los buenos gerentes. Si usted es un gerente de proyecto o de una jerarquía superior, lo que necesita conocer es: marco de resultados, gestión de reuniones, reunir información, construir equipos, comunicar y gestionar su tiempo. Estas cinco características hacen que la gestión de los proyectos requiera, la gestión de más habilidad que la mayoría de la línea de gestión. La gestión de proyectos es una disciplina que requiere su propia aptitud, normas, y formación.

10. ¿QUÉ ES UN PROYECTO DE EXITO? Un proyecto exitoso es aquel que ofrece los resultados esperados. Estos incluyen tradicionalmente un presupuesto, un calendario, y un ámbito de "triple limitaciones" 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 golpear a dos de los tres. Sin embargo, el presupuesto, cronograma, y el alcance son técnicas que definen la forma métrica y como fue gestionado el proyecto. Que tienen poca relación con las preocupaciones reales del cliente.

11. Por ejemplo: Una empresa con $10 millones presupuesto un inventario de $100.000 para un sistema de control de inventario, con la esperanza de reducir el inventario en un 20%, o $2 millones. En el 10% de interés, el sistema hace un recorte de costes de $200.000 por año. El proyecto sufre un 100 por ciento de los sobrecostos. Si la empresa no aplica el sistema o lo hace pero no para reducir su inventario, ha perdido 200.000 dólares-del costo presupuestado más el rebasamiento. Pero si la empresa no aplicara el sistema de inventario y los cortes como se esperaba, se recuperara 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 supera incluso devastadores sobrecostos. El alcance es que el sistema y los beneficios realizados deben aplicarse.

12. ¿Por qué fracasan los proyectos? El más comúnmente culpable es la mala estimación. Existen tres motivos recurrentes que los proyectos fracasan: Cambios de alcance, La mala planificación del proyecto La tecnología.

13. EL CONTROL DEL MEDIO AMBIENTE DEL PROYECTO Una medida de las posibilidades de éxito de cualquier proyecto es el medio ambiente para la gestión de proyectos dentro de la organización. Muchas empresas simplemente parten de proyectos a ejecutar y esperan que las cosas se vallan a trabajar fuera, o al menos que tengan un conveniente chivo expiatorio. Las empresas en las que los proyectos tienen más probabilidades de éxito son aquellas que han establecido estructuras y procedimientos, similares a los siguientes, con el apoyo de sus directores de proyectos.

14. INFORMES Y ESTRUCTURAS DE ESCALA. ¿Qué requisitos para la presentación de informes del estado del proyecto se establecen a los administradores de proyectos? ¿A quién van los informes sobre la situación? ¿Con qué frecuencia? ¿Qué tiene que decir? ¿Qué seguimiento se llevará a cabo sobre las cuestiones planteadas en los informes de situación? ¿Por quién? Hasta que estas preguntas son respondidas, la situación será la presentación inadecuada de informes ad hoc. La existencia de buenas normas de información es un indicio de que la administración se preocupa por el avance de los proyectos y, en consecuencia, está dispuesta a ayudar cuando sea necesario. Otro componente de los informes de estructura es la escalada procedimientos. Cuando los problemas van aumentando, ¿cuál es el procedimiento para hacerlo? ¿Quién debe abordar la cuestión? ¿Cómo? ¿Con qué expectativas? Las empresas que han definido los procedimientos de escalada reconocen algunas cuestiones que requieren la intervención de alto nivel y han definido un mecanismo para proporcionarlas.

15. GESTIÓN DE PROYECTOS DE CARRERA Las empresas cuenta la gestión de proyectos como una importante responsabilidad para las personas. Se aseguran de que los directores de proyectos tienen una clara y conveniente de carrera que incluye la formación, los criterios de promoción, el reconocimiento de los logros, y la oportunidad de progreso a los más altos ejecutivos niveles en la organización. Además, estas empresas, por su reconocimiento de la gestión del proyecto, reconocen que la gestión de proyectos es una disciplina, que es necesaria, y que es digna de fomento. Estas son las empresas que, a su vez, atraen, desarrollan y retienen a los mejores profesionales de la gestión de los proyectos y las capacidades disponibles.

16. ¿CÓMO SABER QUE USTED TIENE UN PROYECTO? Cuando la gente habla de los proyectos, normalmente significa que es largo, caro, evidente, son las decenas de características que distinguen a un sistema de desarrollo de proyectos. 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? ¿Cuando se hacen estos proyectos que requieren la atención de un director de proyecto?

17. El anexo 1.1 proporciona un conjunto de criterios y una lista de verificación que debe ayudar a dar una respuesta. Las actividades involucran a 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 implican un riesgo. Si fracasan las actividades, habrá un impacto significativo. Las actividades requieren la coordinación de dos o más departamentos. Las actividades implican socios de fuera. Las actividades se involucran nuevas tecnologías. Las actividades quedan fuera del alcance de las operaciones normales. Si dos o más casillas son comprobadas, las actividades son un proyecto. Puede que no sea grande, ni podría ocupar gran parte del tiempo de un experimentado gestor de proyectos, pero si no se gestionan adecuadamente, la empresa está en algún grado de riesgo.

18. EL PAPEL DE UNA OFICINA DE GESTIÓN DE PROYECTOS Hasta hace poco, la mayoría de las organizaciones de gestión de proyectos eran tratadas como si la gestión de los proyectos fuera una cuestión de preferencia individual. Las organizaciones han llegado a apreciar que existen dos principales problemas con este enfoque: La gestión de proyectos es una disciplina. Aquellos que no hagan uso de los principios de la disciplina se verán en una lucha de proyectos y, a menudo un colapso. Por lo tanto, la eficacia de la gestión de proyectos es tan irregular como las variaciones en la formalidad. Cuando los directores de proyectos se transfieren a otro proyecto o salen de la organización, es sumamente difícil para sus reemplazos que se hagan cargo de todo, porque la documentación del proyecto se ajusta a las preferencias personales del gestor, en lugar de a un nivel de organización.

19. Algunas organizaciones, intentan crear normas, metodologías de compra para proporcionar la estructura y coherencia a los proyectos. Una vez más, sin embargo, las buenas intenciones son víctimas de tres problemas: La mayoría de estas metodologías se centran en las actividades de los proyectos propios, como el desarrollo, cómo los proyectos se gestionan. Como tal, su utilidad en el establecimiento de normas de gestión de proyectos es mínima. Las metodologías se ocupan principalmente de los proyectos de desarrollo de aplicaciones, haciendo caso omiso de los proyectos de TI en otras áreas tales como las infraestructuras o la planificación estratégica. Cualquier metodología es tan buena como el grado de su uso. Cuando los administradores no hacen cumplir el uso de una metodología, los directores de proyectos lo aprueban incompatible, en todo caso.

20. ¿Cómo hace una organización para crear y hacer cumplir las normas? La respuesta que está ganando una amplia aceptación es la oficina de gestión de proyectos, u OGP (PMO). Una empresa encargada de la disciplina y la práctica de la gestión de proyectos dentro de la organización, o al menos en esa parte de la organización que está bajo su control.

21. Las funciones de una OGP puede variar, pero generalmente se dividen en tres categorías: Funciones de desarrollo. Son los que construyen un grupo de gestores de proyectos eficaces. Funciones de apoyo. Son las que ayudan los gestores de proyectos a ser más eficaz en la gestión de sus proyectos. Funciones de control. Son aquellos que proporcionan la línea de gestión a los directores de proyectos.

22. ALGUNAS OBSERVACIONES SOBRE CICLOS DE VIDA DE PROYECTO 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. Ciclo de vida de desarrollo de sistemas (SDLC) o enfoque de desarrollo. La gestión de proyectos no depende de ningún SDLC o enfoque de desarrollo. Además, asociar la gestión de proyectos con un SDLC es ignorar (o rechazar) la evolución de las formas de desarrollar sistemas. El método convencional "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.

23. GESTIÓN Y PARTICIPACIÓN En muchas organizaciones, el "jefe de proyecto" es también un equipo participante, que espera producir los proyectos, así como gestionar el proyecto. Como si no fuera suficiente carga, el director del proyecto también se espera para participar en la gestión de varios proyectos a la vez. El problema de pedir a un técnico para la gestión de un proyecto, participar como miembro de un equipo es que las personas tienden a hacer lo que les interesa, y qué intereses técnicos tiene la gente de la tecnología. Cuando el proyecto sufre visitas 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?

24. LA GESTIÓN DE MÚLTIPLES PROYECTOS Experimentados gestores de proyectos más pequeños pueden gestionar varios proyectos simultáneamente sin afectar a 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 buen inicio, la planificación, gestión y liquidación. El único problema adicional que usted se enfrenta en la gestión de más de un proyecto es la determinación de aquel en el que gastar su tiempo. En otras palabras, tendrá que ser capaz de establecer prioridades entre sus proyectos y prioridades en su lista de trabajo.

25. ALGUNAS NOTAS SOBRE TERMINOLOGÍA El cliente es la empresa o departamento que especifica lo que se llevara a cabo en el proyecto, paga la factura, y acepta la entrega del sistema. El cliente puede ser un cliente externo, como el de una empresa de consultoría, o un departamento interno. El director del proyecto es la persona responsable de la programación, presupuesto, funcionalidad y aplicación de un proyecto o subproyecto. Muchas organizaciones diferencian entre los directores de proyectos y jefes de proyecto, pero la diferencia es la nomenclatura y, a veces, el tamaño del 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 un paquete de software implementado, 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. Los usuarios son las personas que realmente utilizan los resultados de un proyecto. Para la mayoría de los proyectos, los usuarios forman parte del equipo del cliente, encargado de especificar los requisitos del proyecto.

26. 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 de gestión y conocimientos especializados de gestión de proyectos dentro del contexto de la gestión de los proyectos descritos anteriormente. Una imagen de la gestión del proyecto sería similar a lo que se ve en el Anexo 1.2.

28. Capitulo 2:comprensión del proyecto

29. La gestión de los proyectos requiere la toma de decisiones, que, a su vez, requiere que usted entienda el medio ambiente de proyecto, de fondo, y las personas. En otras palabras, usted necesita entender el contexto cultural y político del proyecto. Por duro que sea admitirlo, la gente es parte más importante de los proyectos que el aspecto técnico. Para gestionar un proyecto, usted necesita entender cuatro cosas: ¿Por qué este proyecto 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? ¿Quien ha luchado por este proyecto? ¿Quien ha luchado en contra de el? ¿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, pero no son exhaustivas. Los proyectos incluyen una mezcla dinámica de las personas con intereses diferentes, filosofías, valores, enfoques y prioridades.

30. SOBRE LA RESPONSABILIDAD FIDUCIARIA (ADMINISTRADORA) La gestión del proyecto no es suave, ni dependen de manera agradable al cliente. A veces, el bien del proyecto requiere que el cliente desafié decisiones o acciones y oponerse a aquellos que ponen el proyecto en situación de riesgo. Como gestor del proyecto, usted es el representante del proyecto: Si pudiera hablar, ¿qué dice? Esta función es común en las empresas y ejecutivos de los miembros de la junta puede ser considerados legalmente responsable por ejercer su "responsabilidad fiduciaria" para actuar en nombre de su empresa.

31. ¿POR QUÉ SE HACE ESTO? El objetivo de el proyecto es crear un estado de la técnica, en línea, en tiempo real, crear un 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 la administración de inventarios. Lo que no nos dice es si el proyecto se justifica-es decir, si va a ahorrar 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. (Si el análisis revela que los costes son mayores, entonces es una justificación para el desguace del proyecto, no para continuar.) Una justificación describe exactamente donde la mejora de los ahorros o ingresos se producirán. 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. Una verdadera justificación, tiene dos características necesarias: Se trata de cuantificar en dólares, y es tratado como un objetivo o meta.

32. JUSTIFICACIONES CUANTIFICADAS EN DOLARES Una justificación describe los beneficios que se derivarán de hacer un proyecto en beneficio de lado un análisis coste-beneficio. Debe ser cuantificados, y si no lo es, nadie sabe si en un principio el proyecto vale la pena o al final si se ha realizado correctamente. Las justificaciones se cuantifican sólo cuando se expresan en términos de dólares (u otra moneda). Las justificaciones deben ser cuantificadas de manera que puedan ser evaluadas y los proyectos pueden ser aprobados sobre la base real de beneficios financieros.

33. LAS JUSTIFICACIONES SON OBJETIVOS, NO PREDICCIONES Una predicción es una conjetura sobre lo que sucederá, una meta es un objetivo a alcanzar. Con una predicción, los resultados del proyecto se dejan a la suerte. Con un objetivo, la justificación se convierte en una cuestión de política, prevista dentro del proyecto global. Se convierte en parte del plan de aplicación del sistema, entra en su ámbito, y se convierte en un conjunto de actividades más que una esperanza de inactividad. Su trabajo es asegurarse de que las justificaciones que las metas de gestión se acepta la responsabilidad de lograr.

34. BENEFICIOS INTANGIBLES Las justificaciones de los proyectos por lo general incluyen una larga y predecible lista de "beneficios intangibles". El problema es que no hay tal cosa, y todos los beneficios se concretan en términos de costes o ingresos. Si llaman un beneficio "intangible" simplemente significa que nadie ha podido-o se ha molestado a adjuntar duros números a la misma. Por ejemplo, considere la posibilidad de flexibilidad. Con un sistema flexible, una de las mejoras es tener menos esfuerzo, produciendo beneficios tangibles de menores costes de mantenimiento y más rápida entrega de las solicitudes de mejora. Además, los departamentos se darán cuenta de los beneficios tangibles que se derivan de las mejoras cuanto antes. La flexibilidad es una ventaja debido a que conduce a resultados reales. El problema es cómo medir los resultados de lo que será.

35. La mejor manera de cuantificar un beneficio intangible es formular tres preguntas: "¿Qué tanto?", "¿Cuánto?", Y "¿Qué hace que el trabajo se lleve a cabo en dólares?“ He aquí un breve ejemplo: Cliente: El sistema será flexible. Project Manager: ¿qué tanto? Cliente: Entonces, vamos a ser capaces de modificarlo con mayor facilidad. PM: ¿qué tanto? 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 se lleve 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.

36. ¿Qué pasa si? EL CLIENTE NO IDENTIFICARA BENEFICIOS. Si el cliente no identificar los beneficios, encontrará difícil tomar decisiones que mejoren el proyecto y la justificación la encontrará más difícil para mantener el proyecto en el ámbito de aplicación.

37. Acciones Crear una "declaración de prestaciones de trabajo", un conjunto de beneficios que se derivan de su comprensión del proyecto y que le parece razonable. Esta será su declaración de beneficios privados, no tendrá la fuerza de una verdadera declaración, sino que le permitirá actuar día a día como si los beneficios estuvieran claramente definidos. Definir el alcance del proyecto en un mucho mayor nivel de detalle de lo normal, y velar por que alcance un sólido mecanismo de cambio está en su lugar. Esto debería ayudar a sobrellevar la dificultad de gestionar el alcance del proyecto sin una declaración clara de los beneficios.

38. El cliente se niega a Establecer metas u objetivos de beneficios Si el cliente define las prestaciones pero no las metas establecidas, encontrará difícil ejecutar el proyecto de tal manera que los beneficios se pueden lograr.

39. Acciones Calcular el nivel de prestaciones que serían necesarias para justificar el proyecto. Por ejemplo, si el cliente quiere reducir niveles de inventario, se debe determinar el nivel de las reducciones necesarias para recuperar el costo del proyecto. Si el nivel de beneficios es razonable, proponer a los clientes como un grupo de trabajo conjunto de las prestaciones, para ser examinado y revisado cuando se ejecuta el proyecto. Si el cálculo de las niveles de prestaciones es razonable, considere la posibilidad de aplazar la fijación de los objetivos de beneficio hasta que usted está planeando para la aplicación en la expectativa de que el cliente esten más familiarizados con el proyecto, la fijación de objetivos será más fácil.

40. El proyecto se está haciendo para utilizar el presupuesto disponible o para hacer el trabajo En este caso, el proyecto se justifica únicamente por su capacidad para gastar el presupuesto de alguien, no tiene justificación intrínseca. Sin embargo, esto no significa que no puede ofrecer valor a la organización.

41. Acciones En este tipo de proyectos, siempre hay una justificación aparente. Pocas empresas ejecutan proyectos abiertamente sin excusa alguna. Actuar en la forma descrita anteriormente para la situación en la que el objetivo del proyecto es real, pero el cliente no identificar los beneficios.

42. El Cliente asume la posición de que la emisión de la justificación de su negocio esta fuera de su alcance 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 papel. Con el fin de gestionar el proyecto, tendrá que estar activamente comprometido con aspectos de su negocio, no sólo desde el punto de vista de la funcionalidad, pero en términos de su contexto en la organización del cliente.

43. Acciones Si es posible, piense en ejemplos, como el proyecto en el que recomendó un cambio importante en la dirección debido a su comprensión del contexto del proyecto y ha creado un producto de más valor como resultado. Informar a su cliente por qué usted lo necesita para comprender la justificación. Describa su papel en la gestión y alcance en los esfuerzos por lograr día a día las decisiones. Si estos intentos fallan, esta claro que las actitudes del cliente obstaculizan la capacidad del proyecto para tener éxito.

44. ¿POR QUÉ debe SER CONSIDERADO CON JUSTIFICACIÓN DEL PROYECTO? Algunos directores de proyecto argumentan que los proyectos no justifican su preocupación, una vez que un proyecto ha sido aprobado, su trabajo es simplemente para 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 en contra de los recortes y los números o cuando los costes cambien.

45. Asegurar que los beneficios se hagan realidad La planificación del proyecto incluye la creación de planes de ejecución, que normalmente consisten en la capacitación, pruebas paralelas, traspaso y eliminación progresiva de los sistemas existentes. Sin embargo, para realmente obtener resultados, el plan de aplicación también debe describir, en detalle, cómo el cliente se debe dar cuenta de los beneficios descritos en el proyecto de justificación. Por ejemplo, si el proyecto se justifica por la capacidad de reducir el inventario en un 15 por ciento, ¿Cuál es la rapidez con que se reduzca el inventario? ¿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 y otras cuestiones similares para todos los objetivos que se fijaron cuando se realizo la justificación del proyecto.

46. La defensa contra recortes Con frecuencia, los nuevos ejecutivos, o los convertidos al evangelio de la reducción de costos, desafían un proyecto en curso. Si la justificación original estaba bien preparada, es razonable, y, lo más importante, en realidad justifica el proyecto, será fácil de defender. El director del proyecto lo justifica de las protestas que alguien más. Pero terminará sin armas para defenderse en contra de la reducción de costes, y es poco probable que el proyecto sobreviva.

47. Reevaluar el proyecto Los costos, beneficios y el cambio de alcance de un proyecto: 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 a superar los beneficios. Una de sus responsabilidades consiste en identificar ese punto y que informe al cliente si las condiciones ya no justifican la continuación del procedimiento. Sin una buena justificación, la tarea es imposible, y el proyecto devora recursos, esfuerzo y mucho tiempo después de que debería haber sido terminado.

48. Evaluación de los requerimientos de cambios de alcance Cuando una justificación del proyecto está bien definida, se puede 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 le costará $ 10000. En caso de que el cambio se haga. Si el proyecto se justifica por el aumento de los ingresos, la pregunta es "¿Cómo y por cuánto, el cambio de la pantalla contribuye a un aumento de ingresos por ventas?" Si la respuesta es más de $10000, "el ámbito de aplicación justifica el cambio. En caso contrario, olvídalo.

49. El establecimiento de las Actitudes del Cliente Una de las razones por las que las personas se resisten a establecer objetivos es el que no se logren. Es fundamental entender que su responsabilidad no es para entregar beneficios, pero sólo para asegurarse de que se han definido y que el trabajo que ha producido se puede utilizar para alcanzarlos. Al discutir los beneficios con sus clientes, usted debe dejar claro que, mientras usted les ayudará a planificar, hacer realidad estos beneficios les corresponde a ellos y que, a menos que estén dispuestos a hacer que el gerente sea considerado responsable de los resultados. Su función es doble: asegurarse de que existe un beneficio y para producir un producto que se puede utilizar para realizar dicha prestación.

50. ¿Qué pasa si? EL CLIENTE NO QUIERE GASTAR RECURSOS PARA LA REALIZACIÓN DE UN PLAN DE BENEFICIOS. Si el cliente no se da cuenta de los beneficios del plan, no funcionara y será en vano

51. Acciones Averigüe las razones del cliente. Normalmente, serán ya sea financiera ("no quiero gastar dinero no tengo que"), de organización ("Eso no es de su competencia"), o basado en programas("No tenemos tiempo para perder con esas cuestiones"). Si es de organización. Lleguen a un acuerdo y pídale a otra persona que elabore el plan de acción. Si las preocupaciones del cliente son financieras o de horario base, preparar un conjunto de argumentos para demostrar que la planificación de beneficios no es irrelevante, pero es fundamental para el proyecto. Revise la lista de personas involucradas con el proyecto y encuentre una que esté en un puesto de alto nivel y que ha manifestado un gran interés en los beneficios. Si ninguna de estas acciones son eficaces, indique al cliente, preferiblemente por escrito, que el proyecto no se puede llevar a cabo ya que depende de la prestación de los beneficios utilizados para justificarla.

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

53. acciones Revise el análisis de costo-beneficio para tratar de encontrar algunos beneficios adicionales o para aumentar los revistos. 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, informe al cliente y continúe. Si no es así, el proyecto ya no está justificado, y debe tratar de convencer al cliente para poner fin al proyecto. Revise el análisis de costo-beneficio para reflejar la posición actual. Indique la pérdida a la empresa si el proyecto se dobla en este momento y la pérdida potencial si se lleva a término. Trate de señalar el lado positivo de poner fin al proyecto. No permita que el cliente tome la posición de que el proyecto ha fracasado. Cambie las condiciones que han hecho aconsejable retroceder antes de que se agoten los recursos y se convierte en un fracaso.

54. ¿QUÉ ES EL CONTEXTO Del PROYECTO? Los gestores de proyectos no suelen participar en el inicio de este. En el momento en que aparecen en la escena, por lo general el proyecto ha adquirido su propia historia y su impulso. Para entenderlo, es necesario pedir a las seis preguntas siguientes: ¿Cuáles fueron las condiciones comerciales que le piden a alguien que proponga el proyecto? ¿Cómo fue presentado el proyecto de gestión, y cómo se evalúa y aprueba? ¿Cuáles son las alternativas de proyecto con que cuenta el cliente? ¿Cuáles fueron (y son) los argumentos contra el proyecto? ¿Cómo ve el cliente el proyecto dentro de la empresa o departamento? ¿Qué tan importante es? ¿Cuáles son las actitudes hacia el proyecto? En concreto: ¿Es acogido como deseable, aceptado como necesario, o condenado como malo? ¿Es considerado como fácil, difícil, o imposible? ¿Es visto con entusiasmo, renuncia, o temor?

55. Mala Actitudes Una de las consecuencias de preguntar sobre los antecedentes del proyecto es que es posible descubrir cosas que hubiera preferido no saber. Por ejemplo, usted puede descubrir que algunas personas que apoyan el proyecto, son pocos los que piensan que tendrá éxito, y que, para muchos, su fracaso en general se consideraría como una señal de que todos tiene razón. Es necesario determinar si este proyecto es realmente una mala idea. Si, después de un examen, se determina que la conclusión de el proyecto es inviable o injustificada, entonces, como gestor de proyectos, es su responsabilidad de señalar al cliente que los detractores son correctas y que el proyecto no debe o no se puede hacer.

56. Si por el contrario e proyecto esta bien justificado y es viable tiene que saber porque la gente normalmente se opone a un nuevo sistema: Lo ven como derivados de las necesidades de otro departamento sin hacer referencia a ellos. Ellos lo ven una imposición. Tendrán que cambiar los hábitos de trabajo cómodo. Sospechan que se trata de una estrategia para alterar la gestión de un equilibrio de las relaciones laborales. Sospechan que no va a funcionar y que su fracaso será culpa de ellos. Reconocen que en el desarrollo y la aplicación será necesario un esfuerzo adicional que no desean. Sospechan (y esto es lo que asusta a la mayoría de ellos) que se traducirá en despidos.

57. ¿Qué pasa si? Usted esta Desalentado de "perder el tiempo" con el fondo. Si no entiende la importancia del background, se arriesga realizando operaciones que ponen en riesgo no solo el proyecto sino su capacidad para dirigirlo.

58. acciones Formular preguntas que se refieren a incidentes específicos de las personas. Por ejemplo, "Fred no parece entusiasmado con este proyecto", o "¿Por qué el departamento de finanzas que no esta representados en el comité de dirección?" 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.

59. Obtiene Información conflictiva del fondo El fondo o el inicio del proyecto suele ocasionar problemas ya que al no estar en el desde esa instancia puede ocasionar distorsiones en la información que se recibe al respecto. Por ejemplo: Fred le dice que María esta en contra del proyecto, pero George dice que ella es una de sus más firmes defensoras-no se tiene información, se tiene un rumor. El riesgo es que se hacen inadecuado, tal vez peligroso, tomar las decisiones.

60. Acciones En el ejemplo que se acaba de dar, usted probablemente aprendido más acerca de la actitud que tienen hacia el proyecto Fred y George y de su actitud hacia María. En esta circunstancia se puede aclarar el rumor directamente con María diciendo: “Entiendo que usted tiene algunas preocupaciones acerca de este proyecto.” sin tener que mencionar a Fred ni a George. Se puede saber que el proyecto es objeto de una lucha de poder.

61. Rivalidad Interdepartamental Si dos o mas departamentos tienen conflicto de opinión con el propósito del proyecto, el alcance o la justificación, tendrá dificultades para gestionarlo y sin importar lo que haga se tendrán oponentes.

62. Acciones Identificar al cliente y los administradores de departamento. Esto puede parecer simple, pero en muchos proyectos, las líneas de responsabilidad son difusas. Por ejemplo, un director de operaciones puede insistir en que el proyecto es responsabilidad de las operaciones, ya que es el departamento que se deben poner en práctica, mientras que el director financiero está reclamando la propiedad debido a que el departamento de finanzas está pagando por ello. Su trabajo es identificar a un solo cliente: el gerente propietario del proyecto y que será responsable de todas las decisiones. Si no está clara la propiedad del proyecto. Esta demanda probablemente desencadenara maquinaciones internas dentro de la organización del cliente, pero siempre y cuando haya realizado su demanda clara, es probable que terminemos con un proyecto efectivo.

63. ¿QUIÉNES SON LOS JUGADORES? "Esto sería un gran proyecto," se lamentan a menudo, "si no fuera por los usuarios." El personal del proyecto anhelan el proyecto de oro en que los usuarios están conformes, las recomendaciones técnicas, normas y "políticas" perfectas no existen.

64. Política vs Sociología La política se refiere a la astucia con que se resuelven las problemáticas del proyecto. La sociología se refiere a la parte de las relaciones humanas a la hora de gestionar el proyecto. Para ver una situación de conflicto o desagrado con políticas es atribuir mala fe a las personas implicadas. Sin embargo, para interpretar la misma situación desde el punto de vista sociológica se debe reconocer que diferentes personas pueden llegar a conclusiones diferentes, pero comparten objetivos y preocupaciones. Evidentemente, la segunda opinión es más probable que lleve a la discusión, aclaración, negociación y resolución.

65. La identificación de los jugadores Para llevar a los participantes en un proyecto de manera eficaz, usted debe comprender quiénes son y cuales son sus actitudes hacia el proyecto. En concreto: ¿Quiénes son los campeones de proyectos, los que han apoyado el proyecto desde el principio y se han entusiasmado con la conclusión de su servicio? ¿Por qué son entusiastas? ¿Quiénes son los detractores del proyecto, los que han luchado en contra del proyecto? ¿Por qué se oponían? ¿Quiénes parecen ganar si el proyecto tiene éxito? ¿Quién van a ganar realmente? ¿Quiénes parecen perder si el proyecto tiene éxito? ¿Quién pierden realmente?

66. El patrocinador ejecutivo El patrocinador ejecutivo es miembro de la dirección que está comprometido con el proyecto y que tiene influencia suficiente para llenar su función primordial. El patrocinador 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.

67. El Comité Directivo El comité directivo del proyecto, 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, el mandato del proyecto. El comité directivo también debe aprobar o negar las solicitudes de recursos adicionales o cambios en el alcance o el calendario. Esto no significa que los miembros del comité de dirección son variables ficticias que no tienen conocimientos especiales que ayuden al proyecto. Los que desean participar a un nivel más detallado se debe permitir que lo haga, pero mantener las funciones por separado.

68. El Grupo de Usuarios El grupo de usuarios es el conjunto de personas que serán responsables del día a día los detalles y decisiones en el proyecto. En el mejor de los grupos de usuarios, una persona tiene la autoridad para tomar decisiones y la voluntad de hacerlo en la cara de la oposición. En el peor de los casos, la "democracia" prevalece y nadie está dispuesto a tomar una decisión. Independientemente del tipo de grupo de usuarios, cuando se necesita una decisión, asegúrese de documentar con claridad los problemas y alternativas. Distribuir la documentación antes de la reunión, y garantizar que nadie sale de la habitación hasta que se alcance una decisión.

69. El cliente director de proyecto El cliente director de proyecto es de los principales miembros del grupo de usuarios del cliente y es el contacto principal entre usted y la organización del cliente. El cliente director del proyecto debe tener la autoridad para aprobar los resultados o para resolver los problemas. Este papel en su proyecto es fundamental.

70. ¿Qué pasa si? El Cliente no designa un patrocinador ejecutivo o designa a uno que no sea superior El proyecto no tendrá a nadie buscando en niveles altos, lo que significa que va a ser vulnerables a la reducción de costes o de un cambio de prioridades y será difícil competir con otros proyectos por los escasos recursos.

71. acciones Cuando usted solicita un ejecutivo patrocinador al inicio del proyecto, determina la antigüedad que necesita ("Esta persona debe ser de al menos un vicepresidente que quiere ver el éxito del proyecto"). Cuando lo haga, procure no molestar al cliente, o tendrá problemas reales.

72. 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.

73. Acciones Identificar un grupo de representantes del cliente a quien usted piensa que debería estar en el comité de dirección y, a continuación, convocar una reunión para discutir una serie de cuestiones para que usted los necesita a todos los presentes. Después de la reunión, manifieste su intención de reunirlos de nuevo cuando surjan problemas en el futuro. Se crea un comité informal, que nunca serán llamados, pero que tendrá la autoridad colectiva para tomar las decisiones que usted necesita.

74. ¿CUÁLES SON LAS PRIORIDADES DEL CLIENTE? Cualquier cliente razonable lo quiere todo: 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 reunión de todos ellos es imposible, y es prudente a entender de antemano lo que puede ser sacrificado. Estas no son las invitaciones a pasar por alto el presupuesto, abandonar el programa, la funcionalidad o la basura, sino que son realistas las declaraciones de las prioridades del cliente, y deben ser respetados. Si el cliente no tiene claras las prioridades, asegúrese de que usted entiende por la comprensión de los antecedentes y la justificación para el proyecto. ¿Cuáles son las consecuencias de desaparecer el calendario? ¿Qué sucede si usted excede el presupuesto? ¿Cuál es el impacto si el sistema no está completo? Una advertencia: No olvidar preguntar al cliente directamente por estas prioridades. "¿Cuál de estos tres se pueden descartar sin que la situación empeore? “

75. ¿Qué pasa si? Obtiene diferentes prioridades de los diferentes grupos de clientes Va a encontrar dificultades para establecer prioridades dentro del proyecto, incluso si está en condiciones de cumplir el plan. Además, esto debería ser una señal de peligro para su proyecto ya puede convertirse en un objeto de la discordia dentro de la organización del cliente.

76. Acciones Al discutir la contradicción con el cliente o el gerente del proyecto y con cada uno de los miembros del comité de dirección. Puede obtener información sobre la organización del cliente que le ayudará a gestionar el proyecto. En general, se debe evitar anunciar este tipo de problema en una reunión donde las personas no han tenido la oportunidad de evaluarlo.

77. INICIO DEL PROYECTO Los proyectos son costosos, por lo que ninguna organización debe comenzar uno sin antes cerciorarse de que dará valor. Sin embargo, en muchas organizaciones, los proyectos parecen surgir de alguna manera. La solicitud se ha convertido en un proyecto encubierto, que es un problema por un período de cinco motivos: 1. No existe ninguna evaluación para determinar cuánto esfuerzo se requiere.2. No existe ninguna evaluación para determinar si el proyecto apoya o retrasa la estrategia de la dirección. 3. No existe una definición clara del ámbito de aplicación. 4. No hay ningún análisis de beneficios, ninguna posibilidad de garantizar que el proyecto ofrece un valor a la organización. 5. Los proyectos regulares de personas que se han extraído de sus horarios y exceder sus presupuestos, aumento de los costos y retrasar la realización de beneficios.

78. Como un director de proyecto, no es su responsabilidad establecer un proceso de iniciación del proyecto: que es el trabajo de gestión o de una oficina de gestión de proyectos. Sin embargo, tiene otras dos funciones. La primera es asegurar que cualquier proyecto que se le 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

79. "Entender el proyecto." ¿Entiende los costes del proyecto y los beneficios? ¿Las justificaciones del proyecto son cuantificables? ¿El cliente acepta la justificación del proyecto 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 ejecutivo patrocinador? ¿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 la gente? (Si no es así, que lo hagan, aunque sólo sea para su propia referencia.) ¿El proyecto se ha iniciado correctamente?