ESTADO DE UN PROYECTO INFORMATICO

¿Cómo se debe informar sobre la Situación de un proyecto ?


Son pocas las personas que saben la forma de informar sobre el estado de un proyecto, incluso cuando son expertos gestores de proyectos. Cual es el problema básico? La mayoría de las personas no entienden la perspectiva de un administrador que está siendo presionado para obtener información acerca de un gran proyecto. . Aquí hay algunas reglas básicas de presentación de informes de estado que se deben utilizar para mantener buena gestión ,que el equipo del proyecto este informado y conducir un proyecto de éxito.
Un estado de presentación de informes significa que los directores estén plenamente informados de sus proyectos del avance y dirección general, sin tener que involucrarse ellos mismos.

A partir de los informes de estado le permite a su jefe pasar sólo unos segundos revisando su informe para determinar qué tipo de progresos ha hecho.

Para escribir un excelente estado del proyecto , usted debe entender:

Los tres componentes de la situación.
Cómo escribir breves detalles.
¿Qué datos clave se necesita por parte de la dirección?

Tres componentes de la situación

Hay tres componentes principales a la presentación de informes del estado del proyecto:

Total: Tenemos que ver lasalud global del proyecto .Como gerentes, queremos ser capaces de detectar un proyecto en problemas. Su proyecto podría no ser tan saludable como usted piensa que es.
Hitos: Su proyecto tiene principales logros que deben ser completado por fechas específicas. Los directores quieren ver que los hitos esten completos, cuáles están en marcha, y que son los que viene.

Temas: Su proyecto también tiene probablemente uno o más obstáculos a la conclusión que se han descubierto. Nos gustaría ver breves detalles acerca de cada tema a fin de que podamos tomar una decisión acerca de si o no al paso y ayudar si es necesario.

Breve Detalles :

Su trabajo es informar sobre los detalles de su proyecto en breve. Podría tenertreinta minutos para escribir su estatuto, pero siempre recuerde que su director no tiene treinta minutos para pasar su lectura.Su gerente realista sólo tiene alrededor de 30 segundos para ver el estado del proyecto, ya que pueden tener 30, 40, 100, o incluso exponencialmente más proyectos para los que son responsables.

Existe un enorme valor en un director de proyecto que pueden informar sin condición narrativa. La recomendación es que lo que se escribe sea como si fueron la creación de un anticuado telegrama.

Datos clave :

Gestión de necesidad de ciertos datos que debe presentar con el fin de ver la salud en general, el desempeño contra metas, y la amenaza de las cuestiones presente proyecto.

Una de las cosas más difíciles que un administrador tiene que ver todo el día se decidirá si para darle más espacio o entrar en su trabajo con usted. La prestación de los hitos del proyecto es útil en este sentido,ya que nos permite ver la programación de alto nivel, determinar si el calendario es aceptable tal como está, y predecir los peligros que pueden enfrentar en el camino.

Los Hitos tienen seis componentes:

El nombre hito.
El porcentaje total de la meta.
El comienzo previsto.
El proyecto final.
El inicio efectivo.
El verdadero final.

En conclución podemos decir que para informar el estado de un proyecto, se debe presentar documentos o entregables que no sean muy extensos ,se debe plantear lo mas concreto posible y que sea entendible,asi estaremos gestionando un buen proyecto.

La mezcla de lo tradicional y ágil en la gestión de proyectos

Diferencias entre tradicional y ágil en la gestión de proyectos

Estuve revisando algunos artículos y hubo uno que me intereso mucho, y que me gustaría compartir con ustedes.
Sabemos que las metodologías tradicionales requieren de disciplina, planificación y métodos de control. Las tareas se completa una tras otra en una manera ordenada siguiendo una secuencia, exigiendo una planificación con antelación.

Las metodologías tradicionales suponen que los acontecimientos que puedan afectar los proyectos son predecibles y que las herramientas y actividades son bien entendidas. Además supone que una vez que cuando una fase está concluida, ya no será renovada. Entonces podemos rescatar los puntos fuertes de este enfoque que establecen las medidas para el desarrollo y subraya la importancia de las necesidades.

Sus limitaciones son que rara vez se siguen el flujo secuencial y a los clientes les resulta difícil completar el estado de los requisitos en una fase temprana del proyecto. Este modelo sueles ser visto como una cascada. En la actualidad los procesos de negocio son más complejos e interconectados. Además rechazan las estructuras tradicionales, ya que la organizaciones hacen frente a las presiones de cambio sin precedentes, la competencia mundial, tecnologías en rápida evolución y creciente complejidad en todo momento. Debido a este carácter multifacético de las empresas, los proyectos que ponen en marcha nuevos sistemas de negocio son más complejo.


Metodología ágil en la gestión de proyectos

Esta metodología es iterativa e incremental en los procesos, donde desarrolladores y partes interesadas en el proyecto trabajan activamente juntos para entender el dominio, lo que es necesario identificar las funcionalidades y darles prioridades. El método agiles se utilizan cuando estas condiciones están presentes: el valor del proyecto es claro, el cliente participa activamente en todo el proyecto, el cliente, los diseñadores y desarrolladores interactúan constantemente.

El enfoque Ágil consta de muchas planificaciones rápidas interactivas y desarrollo de ciclos, lo que permite al equipo de proyecto evaluar constantemente la evolución del producto y obtener de inmediato comentarios de los usuarios o interesados. El equipo aprende y mejora el producto, así como sus métodos de trabajo, de cada ciclo. Después de una racionalización de la planificación, la definición de los requisitos y la solución fase de diseño se ha completado se pone en marcha el proyecto, se realizan repeticiones de una planificación más detallada, las necesidades, diseñar, construir y poner a prueba el sistema. Este enfoque nos permite hacer una inmediata modificación de los requisitos del producto. Esta metodología exige una dedicación plena del equipo de proyecto que incluye un cliente o usuario final, donde los miembros del equipo trabajan en la misma localidad.

Para el desarrollo del trabajo se realizan a través de una serie de sesiones donde el equipo escribe el código, a continuación, pruebas de trabajo de los módulos del sistema y repite el proceso. No hay documentación mínima que el equipo se base, casi exclusivamente en informales comunicaciones internas.

Una vez más, podemos decir que este difiere del enfoque tradicional donde uno invierte una considerable cantidad de tiempo en la planificación y una cantidad significativa de los requisitos de documentación.

¿Entonces cual es la adecuada?

La gestión de proyectos, tradicional o ágil, tiene principios muy similares. Se trata de hacer un buen trabajo para el cliente. Se trata de un líder de equipo. Se trata de entregar resultados de negocio medibles. Muchos de estos principios o prácticas pueden aplicarse en la mayoría de equipo de entornos estructurados.
Sin embargo, algunos profesionales de la gestión de los proyectos pueden rechazar los principios de gestión ágil, si no son capaces de adoptar todos los componentes y las prácticas. Esto es un error. Por ejemplo, ¿qué ocurre si no pueden llegar al usuario a sentarse a tiempo completo con el equipo en el taller? Esto no significa que no pueden incorporar algunas de las otras piezas de gestión ágil, tales como el control visual y de la característica basada en el desarrollo. Además, incluso si un usuario no puede participar en una jornada completa, la mayoría de los usuarios están dispuestos a participar en el equipo, especialmente durante los ensayos y la función de prioridades. El resto del tiempo, el analista de negocios puede representar el usuario, mientras que el completo equipo básico sigue trabajando juntos.

Entonces podemos decir que las técnicas de gestión ágiles en los proyectos promueve un enfoque sobre los beneficios de cada característica. En la gestión de proyectos tradicionales, los equipos se esfuerzan por terminar el proyecto a tiempo y bajo presupuesto y, a menudo, perder de vista los beneficios generales que todo el esfuerzo está destinado a llevaren una organización. De esta manera, los beneficios del proyecto van a ser obvios, si el equipo desarrolla una nueva solución de negocio.

PMBOK y las 9 areas del conocimeinto

Las 9 areas de Conocimiento

La buena gestión de un proyecto informático asegura el cumplimiento de los objetivos:
Como son las especificaciones, los plazos y el coste acordado. Para ello, el jefe de proyecto ha de conocer y utilizar las herramientas y las técnicas más adecuadas en cada situación.

Contamos con estadares para la gestión de proyectos uno de ellos es el PMI(Proyect Management Institute) que es una organización que intenta establecer un orden y unos criterios estándares para la gestión de proyectos. El PMI mantiene el libro PMBOK (Proyect Management Book of Knowledge) donde nos da un conjunto de herramientas y buenas prácticas que todo jefe de proyecto debe conocer y aplicar.

Por tanto se podría decir que el PMBOK como una guía clásica para la gestión de proyecto,no implica que parte de las herramientas que ofrece no puedan ser utilizadas en combinación con otras metodologías más ágiles y flexibles.

El PMBOK define 9 áreas de conocimiento para la administración de proyectos ,estas son:

Integración: Desarrollo del plan de proyecto,ejecución del plan del proyecto y control integrado de cambios.

Alcance: Iniciación,planeamiento del alcance,definición del alcance,verificación del alcance y control del cambio del alcance

Tiempo:Definición de la actividad,actividad que ordena,duración que estima ,desarrollo del horario y control de la actividad del horario

Costo:Planeamiento de recursos, costos estimados, presupuesto y control.

Calidad: Planeamiento de la calidad, aseguramiento de calidad y control de calidad.

Recurso humano: Planeamiento, contratación, desarrollo y administración del Recurso Humano.
Comunicaciones: Planificación de comunicaciones, distribución de la información, funcionamiento de reportesy cierres administrativos.
Riesgos:Planeamiento e identificación de riesgos, Análisis de riesgos (cualitativa y cuantitativa), planeamiento de la respuesta ante riesgos (acción), y supervisión y control del riesgo.
Consecución:Plan de contrataciones y adquisiciones, selección e incentivos de los vendedores, administración y cierre de contratos.