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

Information Systems Project Management - Planning The Project

Embed Size (px)

Citation preview

Page 1: Information Systems Project Management - Planning The Project

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

Page 2: Information Systems Project Management - Planning The Project

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?

¿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

Entendiendo el Proyecto

Definiendo el ProyectoDefiniendo el Proyecto

Ejecutando el ProyectoEjecutando el Proyecto

Planeando el ProyectoPlaneando el Proyecto

Page 3: Information Systems Project Management - Planning The Project

1. Definició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.

Page 4: Information Systems Project Management - Planning The Project

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.

Page 5: Information Systems Project Management - Planning The Project

IdentifíquelosCategorícelosMitíguelosPlanee para ellosSu gestión

Page 6: Information Systems Project Management - Planning The Project

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.

Page 7: Information Systems Project Management - Planning The Project

Riesgos del personalRiesgos del equipoRiesgos del clienteRiesgos del alcanceRiesgos de la tecnologíaRiesgos de entrega Riesgos físicos

Page 8: Information Systems Project Management - Planning The Project

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.

Page 9: Information Systems Project Management - Planning The Project

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 excusasVisibilidad de la demandaLa gente de ayuda se comunica

Page 10: Information Systems Project Management - Planning The Project

Planificación para los riesgosLos 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.

Page 11: Information Systems Project Management - Planning The Project

Gestión de riesgosHay 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.

Page 12: Information Systems Project Management - Planning The Project
Page 13: Information Systems Project Management - Planning The Project

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.

Page 14: Information Systems Project Management - Planning The Project

Lista regular de tipos de supuestosSuposiciones del recursoSuposiciones de la entregaSuposiciones ambientalesSuposiciones presupuestariasSuposiciones de la funcionalidad

Page 15: Information Systems Project Management - Planning The Project

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

Page 16: Information Systems Project Management - Planning The Project

Lista de algunos tipos de limitacionesLimitaciones de recursos Limitantes de entrega Limitaciones ambientales Limitaciones presupuestarias Limitaciones funcionalidad

Page 17: Information Systems Project Management - Planning The Project

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.

Page 18: Information Systems Project Management - Planning The Project

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

Page 19: Information Systems Project Management - Planning The Project

La conformidad con las especificaciones de los proyectos de sistemas de información tiene dos aspectos:

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

2. Los errores deben mantenerse a una mínimo.

Page 20: Information Systems Project Management - Planning The Project

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

Page 21: Information Systems Project Management - Planning The Project

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:

Page 22: Information Systems Project Management - Planning The Project

1. ¿Se cumplen las normas de organización para el diseño, composición, estructura y funcionalidad?

2. ¿Se cumplen las necesidades operacionales en áreas tales como el operador de mensajes o la seguridad?

3. ¿ Se conforma con las comunicaciones o los estándares de la red?

4. ¿Se cumplen los requisitos funcionales?

Page 23: Information Systems Project Management - Planning The Project

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.

Page 24: Information Systems Project Management - Planning The Project

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

Page 25: Information Systems Project Management - Planning The Project

Hoja de Control de Versión:

Page 26: Information Systems Project Management - Planning The Project

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.

Page 27: Information Systems Project Management - Planning The Project

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

Page 28: Information Systems Project Management - Planning The Project

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)

Page 29: Information Systems Project Management - Planning The Project

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.

Page 30: Information Systems Project Management - Planning The Project

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.

Page 31: Information Systems Project Management - Planning The Project

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

Page 32: Information Systems Project Management - Planning The Project

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.

Page 33: Information Systems Project Management - Planning The Project

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.

Page 34: Information Systems Project Management - Planning The Project

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.

Page 35: Information Systems Project Management - Planning The Project

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.

Page 36: Information Systems Project Management - Planning The Project

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.

Page 37: Information Systems Project Management - Planning The Project

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.

Page 38: Information Systems Project Management - Planning The Project

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

Page 39: Information Systems Project Management - Planning The Project

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.

Page 40: Information Systems Project Management - Planning The Project

Definición De DependenciasPara 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?

Page 41: Information Systems Project Management - Planning The Project

Diagramación de PrecedenciaUn 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.

Page 42: Information Systems Project Management - Planning The Project

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

Page 43: Information Systems Project Management - Planning The Project

ESTIMACIÓN DEL PROYECTOCuando 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

Page 44: Information Systems Project Management - Planning The Project

Clasificaciones de recursosLas 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.

Page 45: Information Systems Project Management - Planning The Project

Porcentaje De CompromisoAlgunas 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.

Page 46: Information Systems Project Management - Planning The Project

Periodo vs EsfuerzoEl 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.

Page 47: Information Systems Project Management - Planning The Project

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.

Page 48: Information Systems Project Management - Planning The Project

Pegatina de choqueLa 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.

Page 49: Information Systems Project Management - Planning The Project

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

Page 50: Information Systems Project Management - Planning The Project

Estimación de áreas en peligroEs 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.

Page 51: Information Systems Project Management - Planning The Project

Intervalos de confianzaUn 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%".

Page 52: Information Systems Project Management - Planning The Project

La presentación de la EstimaciónLa 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.

Page 53: Information Systems Project Management - Planning The Project

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

Page 54: Information Systems Project Management - Planning The Project

PREPARACIÓN DEL CALENDARIOUna 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.

Page 55: Information Systems Project Management - Planning The Project

Ruta crítica y Tiempo MuertoSupongamos 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.

Page 56: Information Systems Project Management - Planning The Project

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

Page 57: Information Systems Project Management - Planning The Project

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

Page 58: Information Systems Project Management - Planning The Project

El Papel del Software Para La Gestión De ProyectosSe 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.

Page 59: Information Systems Project Management - Planning The Project

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