El documento presenta una guía sobre cómo planificar un proyecto. Explica los pasos para definir las actividades del proyecto, identificar riesgos y dependencias, estimar los recursos y tiempo requeridos, y desarrollar un plan de calidad y comunicaciones. El objetivo es ayudar a los gerentes de proyectos a organizar y ejecutar proyectos de manera efectiva.

1. Integrantes: León Colorado Josué Sandria Chaparro José Manuel

2. Preguntas generales acerca del tema. ¿He definido los riesgos y desarrollado planes para mitigarlos? ¿He documentado en el proyecto supuestos y limitaciones? ¿He desarrollado un plan de calidad? ¿He elaborado una lista detallada de las actividades del proyecto? ¿He definido las dependencias entre actividades? ¿He construido un proyecto de estimación del trabajo requerido? ¿He asignado recursos y los he nivelado? ¿He completado el programa, con los hitos? ¿He alineado requerimientos del cliente con el calendario? ¿He elaborado un presupuesto del proyecto? ¿He planificado para la implementación? ¿He planificado para la terminación? ¿He planificado para las comunicaciones? ¿He preparado un plan de proyecto? Entendiendo el Proyecto Definiendo el Proyecto Ejecutando el Proyecto Planeando el Proyecto

3. 1. De finición de los riesgos del proyecto y determinar las medidas para mitigarlos. 2. Listado de los supuestos y limitaciones del proyecto. 3. Determinar cómo se gestionará la calidad. 4. La elaboración de una lista de actividades y los componentes de costos. 5. Establecimiento de dependencias entre las actividades. 6. Estimación de esfuerzo y los costos. 7. La preparación de un calendario y los hitos. 8. Nivelación y la asignación de los recursos del proyecto. 9. Alinear el presupuesto y el calendario de los requisitos del cliente. 10. Preparar el presupuesto del proyecto. 11. Gestión de trámites de proyectos. 12. Planificación de la aplicación. 13. Planificación para la realización. 14. La planificación de las comunicaciones. 15. Escribir el plan de proyecto.

4. Un riesgo es un problema potencial, una situación que, si se materializa, afectará adversamente el proyecto. Los riesgos que se materializan se convierten en problemas.

5. Identifíquelos Categorícelos Mitíguelos Planee para ellos Su gestión

6. Identificación de Riesgos del proyecto Se responde a la pregunta ¿Qué puede ir posiblemente mal? La forma de mitigar algún riesgo tomado como peligroso es documentar todos los demás riesgos, identificar las acciones que tomar, y mantener informado a la gestión, sobre todo porque el riesgo se vuelve más probable.

7. Riesgos del personal Riesgos del equipo Riesgos del cliente Riesgos del alcance Riesgos de la tecnología Riesgos de entrega Riesgos físicos

8. Categorizando riesgos La clasificación más simple, y la más eficaz, es describir los riesgos como la extrema, alta, media, baja o mínima. El grado de riesgo depende de dos características: la probabilidad de que se produzca el riesgo y el impacto en el proyecto si lo hace.

9. Mitigación de riesgos La mejor forma para mitigar un riesgo es reduciendo su probabilidad, su impacto, o ambos. Siempre hay que toma en cuenta algunos principios tales como: Quite las excusas Visibilidad de la demanda La gente de ayuda se comunica

10. Planificación para los riesgos Los planes de contingencia son los pasos que usted seguirá cuando un riesgo se materializa. Hay dos aspectos del planeamiento del riesgo que afectarán su plan del proyecto: mitigación de actividades y planes de contingencia.

11. Gestión de riesgos Hay tres mecanismos principales para la gestión de riesgos: reuniones del equipo de proyecto, informes del proyecto, y reflexión del encargado de proyecto . Para gestionar riesgos, usted debe asegurarse de que se manifieste una parte del equipo de proyecto, y su, sentido. Prepare una hoja de trabajo de la gestión de riesgo.

13. Cuando los proyectos tienen problemas, con frecuencia la causa es un supuesto que resultó ser inválido o una limitación que nunca fue identificada.

14. Lista regular de tipos de supuestos Suposiciones del recurso Suposiciones de la entrega Suposiciones ambientales Suposiciones presupuestarias Suposiciones de la funcionalidad

15. Las limitaciones son límites o fronteras dentro de las cuales usted debe trabajar.

16. Lista de algunos tipos de limitaciones Limitaciones de recursos Limitantes de entrega Limitaciones ambientales Limitaciones presupuestarias Limitaciones funcionalidad

17. Identificar ¿por qué los supuestos y limitaciones? La mayoría de los supuestos y limitaciones deben ser explícitos, por dos razones: Primero , su cliente, su gerencia, y usted necesitan entender la base sobre la que están planeando. La segunda razón para identificar los supuestos y limitaciones es para ayudarte a la hora que usted necesita para negociar con el cliente durante el proyecto.

18. La calidad es una parte cada vez más importante de la gestión de proyectos.

19. La conformidad con las especificaciones de los proyectos de sistemas de información tiene dos aspectos: El producto resultante del proyecto debe ajustarse a los requisitos o especificaciones que se señalaron para ello normalmente a cargo de la gestión de alcance y las expectativas del cliente Los errores deben mantenerse a una mínimo.

20. Error Costo Consecuencias Errores de programación Unidad de prueba y depuración de tiempo Depuración y revisión durante la integración Después de la liberación de mantenimiento del sistema Formato del archivo de datos o errores de diseño Depuración y revisión durante la integración La documentación de los errores de usuario Asistencia a los usuarios Reescribiendo la documentación Sistemas de documentación de los errores Después de la liberación de mantenimiento del sistema Apoyo de mantenimiento programadores Reescribiendo la documentación Errores en la especificación de requisitos Identificar los requisitos de errores durante los sistemas de aceptación Revisar el sistema Informe de errores en los diseños, los cálculos, la secuencia, o totalización. Identificar los requisitos de errores Revisión de informes

21. Revisión de par La revisión de par, como el término implica, significa que los pares técnicos de un miembro del equipo repasan el producto antes de que se lance. Esta revisión se realiza normalmente en un walkthrough, que es una reunión técnica convocada para el propósito único de repasar un entregable. Los revisores deben ser referidos a los aspectos siguientes del entregable:

22. ¿Se cumplen las normas de organización para el diseño, composición, estructura y funcionalidad? ¿Se cumplen las necesidades operacionales en áreas tales como el operador de mensajes o la seguridad? ¿ Se conforma con las comunicaciones o los estándares de la red? ¿Se cumplen los requisitos funcionales?

23. Guía de trabajo de revisión muestra: las listas de los participantes en el examen y el listado de los cambios que los revisores y el autor de acuerdo a. También se da el miembro del equipo de la estimación de la fecha de vencimiento de cada una revisión y un indicador de que el cambio se ha hecho.

24. En cualquier proyecto en el que los miembros del equipo confían en los resultados que producen otros miembros del equipo, tendrá que asegurarse de que existe un mecanismo que: Identifica diferentes versiones de los productos  Describe las diferencias entre versiones  Permite que cualquier miembro del equipo para encontrar la versión actual

25. Hoja de Control de Versión:

26. Gestión de la calidad se separa normalmente en el aseguramiento de la calidad y control de calidad. El papel de garantía de calidad (QA) debe asegurar que los procedimientos son en el lugar que conducirá al desarrollo de un producto de calidad. El control de calidad (QC) es la gestión cotidiana de aquellos procedimientos en todas partes del proyecto. Ambos son necesarios para asegurar que el proyecto produce uno de producto de calidad que se conforma a sus exigencias y es sin error.

27. La planificación es el acto de determinar lo que debe hacerse cuando. El propósito de la planificación consiste en permitir que para hacer funcionar el proyecto se debe adoptar las medidas necesarias para garantizar que se completarán a tiempo y dentro del presupuesto..

28. Para seguir progreso , el proyecto se debe analizar en actividades pequeñas, manejables. Comenzar actividades del listado y esperar que las que falten no le hunda. Hay una alternativa, un enfoque sistemático conocido como descomposición jerárquica. La descomposición es el proceso de romper una actividad en pequeños trozos. Jerárquico significa que procede la descomposición de arriba hacia abajo definiendo los componentes principales del proyecto, entonces rompiendo cada componente en pedazos más pequeños. El resultado es la estructura de desglose de trabajo (WBS)

29. Un WBS es una lista de todas las actividades del proyecto, organizadas jerárquicamente en niveles. También incluye los gastos, tales como compras de equipo, viajes, materiales, o las tasas de los cursos de formación.

30. Puesto que un WBS es jerárquico, sus elementos se pueden numerar en niveles. Uno de los principales usos de los números de WBS es a la hora de presentación de informes. Los miembros del equipo de tiempo completo de las hojas, el cobro de su tiempo a actividades específicas identificadas por número de WBS. El número se utilizará también para determinar las actividades en el calendario, así como los gastos en el presupuesto.

31. En el nivel más bajo, una WBS consiste en tres tipos de componentes: Actividades de trabajo, las actividades distribuidas, y los costos.

32. Actividades de trabajo: son aquellos que contribuyen a un producto claramente definido. Actividades distribuidas : son las que no producen resultados directamente, pero se requiere de los miembros del equipo de proyecto a lo largo del proyecto. Componentes de los gastos son costos que no son directamente soportados por las actividades laborales. Ejemplos de ello son los materiales, costes de adquisición de hardware o software , y gastos de viaje.

33. El primer paso en la preparación de un proyecto WBS es identificar los principales conjuntos de actividades. Y nos da una posible lista de las principales actividades tomando como ejemplo la selección de hardware y software.

34. Actividades que faciliten la gestion, coordinación, y el control. Actividades para seleccionar y para adquirir el hardware o el software. Actividades a construir y prueba de unidad el sistema. Las actividades para integrar los sistemas y prueba del sistema. Las actividades que involucran a los usuarios . Las actividades para implementar el sistema.

35. Al grado posible, las actividades deben ser independientes de una otra. Es decir, cada actividad se debe de realizarse con el menor conocimiento de las otras actividades como sea posible.

36. El diseño de actividades para ser independiente tiene tres ventajas principales: 1. El personal puede ser más fácilmente transferidos entre las actividades. 2. Es posible añadir más personal, si el calendario se desliza. 3. La necesidad de comunicación a través de actividades es reducido. Que se traduce en menos confusión, menos oportunidades de malentendidos, y un proyecto agradable.

37. Un problema con cualquier descomposición está sabiendo cuándo parar. Obviamente, las actividades se puede dividir en los niveles de detalle tan delicado que cada hora de cada miembro del equipo del día para la duración del proyecto está previsto.

38. Con frecuencia, usted no puede completar una WBS porque no sabe cómo se llevará a cabo la mayor parte del proyecto. Es separar el proyecto en fases ..

39. La primera fase suele ser el análisis, definir el ámbito de aplicación, o realizar cualquier actividad que le permitirá identificar claramente su enfoque y las actividades para el proyecto principal. En tal caso se puede construir una WBS detallado para la fase de análisis y un esqueleto para el resto del proyecto.

40. Definición De Dependencias Para definir dependencias, examinar las actividades de trabajo, y, para cada uno, haga las siguientes preguntas: ¿Qué actividades de trabajo debe terminar antes de que este pueda iniciar? ¿Qué actividades de trabajo debe terminar antes de que esta pueda terminar? ¿Qué actividades de trabajo debe iniciar antes de que este pueda iniciar? ¿Qué actividades de trabajo debe comenzar antes de que esta pueda terminar? Para cada dependencia, ¿lo que los tiempos de retraso o hacer las actividades imponer?

41. Diagramación de Precedencia Un diagrama de precedencia es una imagen de las relaciones de dependencia. Algunos directores piensan que los diagramas son una herramienta esencial de planificación, mientras que otros los consideran una pérdida de tiempo. Como una presentación visual de las dependencias, son útiles en la realización de revisiones o determinando erróneas o inválidas dependencias, y sin duda expresa la complejidad del proyecto.

42. ¿Qué pasa si? Sus dependencias son desafiadas Las dependencias son el núcleo de la programación. Sin ellos, todo se puede hacer a la vez, y el proyecto no sería más largo que la actividad mas larga. Si sus dependencias no son correctas, su programación será inexacta. Si hay demasiadas dependencias, el programa ocupara más tiempo del necesario. Si hay muy pocas, el programa será imposible de cumplir. Acciones Revisar los desafíos, y, si tiene sentido, modificar en consecuencia sus dependencias. En caso contrario, deje el calendario como está. Si la dependencia que está siendo desafiada es metodológica, pedir al desafío que se comprometan a aliviar la dependencia. Por ejemplo, si se les dice, "No necesitamos esperar a la aprobación del diseño antes de comenzar la codificación," la metodología y dice que lo haga, pedir al desafío de un compromiso que permite una desviación de la metodología para este proyecto. Si usted no recibe uno, con su palo plan original.

43. ESTIMACIÓN DEL PROYECTO Cuando se está preparando una estimación, se entiende que: La estimación no es el presupuesto. La estimación indica la gestión, incluyéndolo a usted, de cuánto esfuerzo se necesita para completar el proyecto. El presupuesto te dice cuánto va a costar el proyecto. Tratar a las estimaciones con esfuerzo expresado en períodos como días de trabajo. Tratar los presupuestos en dólares

44. Clasificaciones de recursos Las actividades son llevadas a cabo por personas, pero por lo general comienza con la planificación de las clasificaciones, como arquitecto de tecnología, analista de sistemas, programador o analista. Para llevar a cabo una estimación, es necesario saber qué tipos de habilidades son necesarias en cada actividad, y las habilidades con que cuenta el personal. Que, en última instancia, tienen que poner nombres a cada actividad, pero, por ahora, se trata de dejar que su gestión de saber cuántas de qué tipo de personal que necesita.

45. Porcentaje De Compromiso Algunas personas de requieren de tiempo completo en una actividad, mientras que otros necesitan menos. Por lo general, más personal subalterno son a tiempo completo en actividades como el programa de codificación, mientras que altos funcionarios están divididos entre diferentes actividades, a tiempo parcial en cada uno.

46. Periodo vs Esfuerzo El trabajo requerido de una actividad puede ser estimado como un período o como un esfuerzo y se expresa en duración. Si calcula una actividad como un período, usted esta estimando un tiempo transcurrido, como cuatro semanas. Una actividad de cuatro semanas tomara cuatro semanas, independientemente del número de personas que se le asignen. Si calcula una actividad como un esfuerzo, usted esta estimando un período de trabajo, como cuatro semanas. Una actividad de cuatro semanas tomara a una persona cuatro semanas, dos personas dos semanas, o una persona a media jornada ocho semanas.

47. Principios Para La Evaluación Sus estimaciones mejorarían si se respetan estos principios: Base sus estimaciones sobre el rendimiento de la media de personal. No asuma que las superestrellas estarán disponibles. (Si es así, dejar claro que se espera que superen la estimación). No haga caso de cualquier programa de limitaciones externas. Esto significa disponibilidad a tiempo parcial o los plazos del proyecto. Estas serán tomadas en cuenta más tarde, pero no deben afectar a la estimación. Asegúrese de que todas las estimaciones son completadas por quienes están o estarán calificados para hacer el trabajo. En primer lugar, las estimaciones serán más precisas. En segundo lugar, haciendo la estimación implica un compromiso. Es razonable decir a un miembro del equipo, "Usted ha dicho que esto tome tres semanas, por lo que tres semanas es lo que tienes.” Las estimaciones son revisadas por gente con conocimientos. En particular, pregúnteles para ver una sobreestimación por parte del personal que han decidido construir en gran escala los factores de seguridad.

48. Pegatina de choque La primera vez que completa un presupuesto para su proyecto, usted puede sentirse como si se hubiera multiplicado la duración en vez de añadir, el esfuerzo total parece ridículamente alto. En un intento de obtener las estimaciones a un nivel razonable, muchos estimadores vuelven a la WBS y comienzan a calcular las actividades en los niveles superiores. Por ejemplo, si las actividades para completar un programa de evaluación añadieron hasta dos meses de trabajo, existe la tentación de mirar el conjunto de las actividades de evaluación y decir: "Esto no puede ser más que un mes" y descartar la estimación original. De esta forma se encuentran problemas.

49. Contingencia Una contingencia es un subsidio para los problemas. Es mejor decirlo abiertamente como una actividad en el WBS que enterrarlo secretamente en cada actividad laboral. Si es abierta, puede hacer explícita la decisión de utilizar una parte de él y dirigir a las áreas problemáticas. Si se oculta, no sólo no puede ser utilizada oficialmente, pero las estimaciones para las actividades de trabajo individuales son exageradas por la cantidad de la contingencia. La consecuencia inevitable es que el trabajo se ampliará para ocupar el inflado período de tiempo, la contingencia se utilizarán, el proyecto tomará más tiempo de lo que deberían, y, cuando surgen los problemas, no habrá dejado de contingencia para hacer frente a ellos.

50. Estimación de áreas en peligro Es un cliché, con el apoyo de un sinfín de sobrecostos del proyecto, esta gente de sistemas de información son pobres estimadores. Sin embargo, la realidad no es tan simple. La mayoría de la gente es bastante precisa en la estimación de las actividades que han realizado antes. Las estimaciones para la codificación, documentación, formación, e incluso análisis tienden a estar cerca de los números reales.

51. Intervalos de confianza Un margen de confianza es una gama de estimaciones dentro del cual se sienta cómodo para que el proyecto quede completado. Por ejemplo, durante la etapa de iniciación, cuando todavía hay un montón de incertidumbres, usted no debe sentirse cómodo indicando que el proyecto tendrá 1.250 jornadas de esfuerzo. Típicamente, las estimaciones de un proyecto en el inicio podrían ser por tanto como 100 por ciento, lo que significa que el rango puede variar de cero a 2.500 jornadas de trabajo. Es evidente que el cero de la gama es tonto, pero el proyecto puede completar en tan sólo 1.000 jornadas de trabajo con un poco de suerte. Se puede expresar, por lo tanto, la estimación de 1.000 a 2.500 jornadas de trabajo o, en términos porcentuales, "1.250 de trabajo + 100% - 20%". En la terminación de la definición de los requisitos, sus estimaciones podría ser expresado como "1.250 jornadas de trabajo + 50% -10%", y, una vez haya finalizado el diseño, como, "1.250 de trabajo + 10%".

52. La presentación de la Estimación La estimación se expresa como una jornada laboral (o de trabajo o mes de trabajo) por exigencia de la clasificación. Por ejemplo, un proyecto necesita 150 días de trabajo de gestores de proyectos, 300 de analista de sistemas, 750 de desarrolladores, 50 de aseguramiento de la calidad, 50 de apoyo de oficina. Este tipo de estimación permite a la gestión reconocer la magnitud del proyecto y los recursos que serán necesarios.

53. ¿Qué pasa si? Sus Estimadores se presentan ante usted con estimaciones que en su opinión son demasiado bajos Si sus estimaciones son bajas, su proyecto rebasara a su plan y el presupuesto, y usted y su equipo se sienten frustrados en el intento de satisfacer un conjunto de objetivos imposibles. Acciones Aclarar en su propia cuenta por qué piensa que las estimaciones son bajas. Esto podría ser debido a su experiencia en proyectos similares o porque sabe que esta estimación es siempre optimista. Presentar sus preocupaciones a la estimación y pedir un compromiso de completar el trabajo dentro del tiempo estimado. Si el estimador se niega a cambiar las estimaciones, pero no para convencer a los que son realizables, preparar su plan de proyecto a través de su más alta estima. Sin embargo, si durante el proyecto puede asignar el trabajo a la estimación, el uso de estimaciones más bajas que se le ha dado. Si el miembro del equipo cumple con los más bajos calendario, se ha llegado en menos de presupuesto. Si no es así, la programación tendrá en cuenta el "desvío", y tendrá algunos antecedentes para juzgar mejor las futuras estimaciones.

54. PREPARACIÓN DEL CALENDARIO Una de las cosas que los directores de proyectos se suponen que debemos hacer es cumplir con el plazo que, por supuesto, implica tener un calendario a cumplir. El calendario es una de las dos partes principales del plan de proyecto (el presupuesto la otra), y, como lo es complejo, es un subproducto de la labor que ya se ha realizado. La elaboración de un programa requiere una lista de actividades y de sus dependencias y duraciones. Con estas piezas y, al menos, una fecha fija, el programa sigue automáticamente.

55. Ruta crítica y Tiempo Muerto Supongamos que hay dos programas para ser escrito. Requiere un programa de cuatro semanas y el programa B, tres. Ambos pueden comenzar al mismo tiempo, y la integración se iniciará cuando ambos están acabados. Actividades con cero tiempos de holgura se llaman críticas, porque no pueden deslizarse sin que ello afecte a la totalidad del proyecto previsto.

56. Hitos Un hito es una fecha específica en el proyecto claramente definido cuando algunos trabajos se han realizado. Muchos planes del proyecto acaban de dos etapas, de inicio y fin, lo que significa que el administrador del proyecto no sabe cómo el proyecto se debe hacer hasta que haya terminado.

57. El gráfico de Gantt Un diagrama de Gantt es un gráfico de las actividades a lo largo del tiempo. Es la forma más eficaz de presentar un plan del proyecto y de su progreso. En su forma básica, un diagrama de Gantt consiste en una línea para cada actividad que se ejecuta a lo largo de una escala fecha. La línea de puntos inicial y final especificar cuando la actividad se llevará a cabo. Variando los símbolos, un diagrama de Gantt puede indicar: Hitos Tiempo de holgura Actividades en el camino crítico

58. El Papel del Software Para La Gestión De Proyectos Se puede argumentar que la característica más importante de la gestión de proyectos de software es su capacidad para producir un calendario. Basta con introducir los datos de actividad y el diagrama de Gantt aparece automáticamente. De hecho, muchos paquetes le permitirán construir el programa gráficamente.

59. ¿Qué pasa si? Insiste en su cliente de tener menos hitos exteriores Va a tener la tentación de cumplir. Después de todo, los hitos son externos, en el mejor de las molestias y en el peor de los desastres. Sin embargo, su propósito es garantizar a ambos el cliente y que el proyecto está en marcha. Sin la disciplina de tener que reunirse con ellos, corre el riesgo de que el proyecto de resbalamiento y que se aparten del plan funcional. Acciones Determinar por qué el cliente se opone a hitos. La mayoría de los clientes con ellos en una oportunidad de mantenerse al corriente sobre el estado del proyecto. La objeción más común es que las demandas de los clientes hacer hitos personal. Tratar de negociar algún tipo de revisión o de control para cada uno de sus hitos. Incluso si la revisión es superficial, es mejor que no tener contacto con el cliente. Gestionar el proyecto como si se los hitos en su lugar, y designar como representante del cliente.