crashing

• Liderazgo.
• Habilidad de comunicar.
• Negociación.
• Resolución de problemas.

Este es uno de los factores claves para asegurar el exito de un proyecto, por lo tanto se deben tener en cuenta las siguientes condiciones en el levantamiento de requerimientos e identificacion de necesidades:

• Identificar al Patrocinador del Proyecto (Sponsor): Es la(s) persona de alto mando que defiende al proyecto en las altas esferas de la compania, consigue recursos, compromete a la gente y empodera al gerente del proyecto y su equipo. Tambien sirve como nivel superior de escalamiento ante problemas.

• Identificar a los usuarios lideres: Son las personas que conocen los procesos y/o tecnologias que seran mejoradas/automatizadas en el proyecto. Deben participar a lo largo del proyecto y se debe garantizar un porcentaje minimo de su tiempo a las labores del proyecto. Su rol es principalmente importante en la etapa de levantamiento de requerimientos, durante las pruebas y puesta en produccion, asi como en la etapa postproyecto involucrados en el subproyecto de Gestion del Cambio.

• Identificar los niveles de aprobacion de funcionalidades: Usualmente el sponsor delega este rol en los usuarios lideres o expertos.

La siguiente deberia ser la estructura minima del documento de levantamiento de funcionalidades o requerimientos:

• Titulo del requerimiento o funcionalidad
• Descripcion general de la funcionalidad
• Control de versiones: Numero de version, fecha de actualizacion, descripcion cambios realizados, quienes solicitan y aprueban los cambios. Esto permite tener el historico de la evolucion de los posibles cambios de una funcionalidad desde su levantamiento inicial hasta su implementacion final y puesta en produccion. Recuerde que los usuarios al final solo se acordaran que el proyecto se atraso pero no que ellos pudieron ser los causantes al solicitar constantemente cambios a los requerimientos originales.
• Describir el funcionamiento deseado
• Describir las fuentes de datos y sistemas involucrados (si aplica).
• Describir a los actores involucrados y cual es su rol.
• En lo posible hacer un diagrama de flujo que muestre las actividades, secuencia y actores.
• Describir las pre-condiciones y post-condiciones del proceso.
• Dejar claro cuales son los supuestos.
• Definir los criterios de aceptacion de la funcionalidad.

Recuerde comunicar los requerimientos y sus cambios, asi como obtener las aprobaciones (firmas fisicas o digitales) que formalicen la solicitud y/o cambios. En lo posible publique los documentos en un centro de informacion al que tengan acceso los actores del proyecto (una wiki podria funcionar muy bien para mantener la documentacion de manuales de usuario y desarrollo, pero podria quedarse corta para administrar documentos controlados y firmas digitales... Al menos por ahora ;) ).

Dado el gran volumen de tareas que se desarrollan en un proyecto tipico una herramienta indispensable es el action item register o plantilla de seguimiento de pendientes.

Esta consiste basicamente en una lista de actividades que puede ser llevado en una hoja de calculo que contenga el listado de tareas, prioridades, fechas de compromiso, responsables etc. Y deberia ser revisada durante las reuniones de seguimiento tecnicas y/o directivas segun aplique.

Los siguientes son los campos minimos de seguimiento que deberia tener el listado de tareas pendientes:

• Titulo de la actividad pendiente.
• Descripcion detallada (si lo requiere).
• Fecha solicitada de terminacion (cuando deberia terminarse)
• Fecha comprometida de terminacion (a la que se compromete el responsable).
• Fecha mas probable de terminacion (segun el avance actual cual es la fecha mas probable de terminacion). Estas tres fechas permiten determinar las desviaciones entre lo solicitado, comprometido y real terminada, y su resultado deberia usarse para mejorar tiempos estimados a futuro y documentar las lecciones aprendidas.
• Prioridad (tipicamente alta, media y baja): No deberian tenerse demasiados niveles de prioridad ya que en cierto punto no se hace una diferenciacion real entre los niveles, tipicamente se manejan entre 3 y 5 niveles.
• Persona responsable.
• Equipo de apoyo: Quien colabora al responsable en la resolucion.
• Estado: Abierto, Cerrado, En proceso (WIP), En espera(standby).
• Avance: Porcentualmente que avance se tiene.
• Comentarios adicionales.

Esta es una combinacion entre la teoria de Risk Management del PMI y el Modo a prueba de fallos o FMEA (Failure Mode and Effect Analysis) de la metodologia Six Sigma.

Basicamente consiste en identificar todos los riesgos potenciales de un proyecto (o sistema si ya esta en produccion) y cuantificar su probabilidad de ocurrencia e impacto, con base en esto se calcula un indice de riesgo que permite priorizar los riesgos que se deben mitigar y enfocar primero los esfuerzos en los que la multiplicacion del nivel de gravedad y la probabilidad de ocurrencia, es decir los que mas duro le pegan al proyecto pero tambien que tienen una alta probabilidad de ocurrencia.

Se deben tener en cuenta los siguientes parametros para el FMEA:

• Descripcion del riesgo.
• Probabilidad de ocurrencia (1-10) siendo 10 una alta probabilidad de ocurrencia y 1 la minima.
• Impacto del riesgo en el negocio o proceso (1-10) siendo 10 un riesgo que afecta altamente al negocio y 1 una afectacion minima.
• Nivel actual de deteccion (1-5): Si hoy en dia existen controles para detectar a tiempo el problema y resolverlo se debe calificar 1 cuando los controles actuales son muy buenos y 5 cuando no existe ningun control para detectarlo o mitigarlo.
• Indice de riesgo: Es la multiplicacion de la posibilidad de ocurrencia x impacto x nivel de deteccion. Los riesgos con mayor indice de riesgo deben ser los primeros en resolver.3

. Matriz de responsabilidades (RAM)====

Puedes hacer click en los componentes del mapa mental para abrirlos o cerrarlos, tambien “agarrar” la pagina para deplazar a izquierda, derecha, arriba o abajo si no cabe en el marco de visualizacion. Utiliza los botones para hacer zoom, cambiar el fondo etc.

Curso ITIL

Curso SOA

Examen de certificacion PMP

El PMI

El PMBOK

Teoria de gerencia de proyectos

Como implementar una wiki en las empresas. Tips, recomendaciones e implementacion de una wiki para gestionar el conocimiento.

preguntas examen pmp