miércoles, 12 de abril de 2017

Gestión de Portafolio


Publicar y Republicar Asignaciones de Trabajo


Visión General del Project Web Access


Actualización del Progreso a través del Project Web Access


Análisis del Project Server


Seguimiento del Proyecto a través del Project Web Access


El centro de Recursos


Uso de la Página Principal


Informes de Estado


Levantamiento de Información


GP usando MS Project 2003: Planificación 5


GP usando MS Project 2003: Planificación 1


Liderazgo, Poder, Influencia y Políticas en la Gestión de Proyectos


Guía del PMBOK® > Gestión del Tiempo (Parte 1)


Guía del PMBOK® > Gestión del Tiempo (Parte 2)


Guía del PMBOK® > Gestión del Tiempo (Parte 3)


Guía del PMBOK® > Gestión de Costos


Guía del PMBOK® > Gestión de la Calidad


Guía del PMBOK® > Gestión de los Recursos Humanos


Guía del PMBOK® > Gestión de Riesgos


Comunicación


Guía del PMBOK® > Gestión de las Adquisiciones


lunes, 10 de abril de 2017

Recomendaciones para el Examen de Certificación PMP®


Proceso de Certificación PMP®


Guía del PMBOK® > Gestión de Integración


Siete pecados capitales del Project Management


Business Process Management


Organizational Project Management Maturity Model (OPM3®)


Cycle Counting > Cómo elevar los niveles de IRA


Guía del PMBOK® > Marco Conceptual (Parte 1)


Guía del PMBOK® > Marco Conceptual (Parte 2)


Gestión del Alcance, Tiempo y Comunicaciones


Gestión de los Riesgos, Adquisiciones y Financiera


Gestión y Gobierno de Portafolios


GPY051 Proceso de Certificación(PMI-RMP)


Curso de Preparación para la Certificación (PMI-RMP)® – Identificar los Riesgos.


Curso de Preparación para la Certificación (PMI-RMP)® – Realizar el Análisis Cualitativo de Riesgos


Curso de Preparación para la Certificación (PMI – RMP)® – Realizar el Análisis Cuantitativo de Riesgos


Curso Taller de MS Project 2010 – Revision y Ajuste del Plan del Proyecto


Curso Taller de MS Project 2010 – Configuración de la Línea Base


Curso Taller de MS Project 2010 – Actualizacion del Seguimiento del Proyecto


Curso Taller de MS Project 2010 – Control del Proyecto usando el Valor Ganado


Curso Taller de MS Project 2010 – Cierre del Proyecto


Herramientas Avanzadas para la Gestión de Proyectos – Introducción al WBS Chart Pro


Herramientas Avanzadas para la Gestión de Proyectos – WBS Chart Pro en la Gestión de Proyectos


Los Recursos en los Proyectos


Problemas en la Asignación de Recursos

Le han entregado un proyecto y también algunos recursos preasignados para trabajar en él. Sin embargo, en un mundo ideal, primero identificaría sus requerimientos de recursos y luego buscaría personas con las características necesarias para cumplir estos roles. Ahora no tiene más remedio que trabajar con estas personas en particular. Algunos encajan en los requerimientos para los recursos y otros presentan grandes deficiencias en sus habilidades y experiencias. ¿Qué hará ahora?

Recursos en los Proyectos

En el mundo real, raramente obtenemos los mejores recursos para un proyecto. Usualmente lo que se obtiene es una mixtura de recursos que están disponibles, y recursos que tienen alguna relación con el tema del proyecto. Desafortunadamente, esta es la realidad de los negocios hoy en día. Las organizaciones deben usar sus recursos y asignarlos según su disponibilidad. Considérese extremadamente afortunado si realmente obtiene las personas más competentes en todas las áreas que necesita.

Aceptando lo Inevitable

La gestión de recursos puede implicar el decir “No” a los recursos asignados, pero en la mayoría de casos la directiva que le darán será sacarle el máximo provecho a los recursos que le fueron asignados. Esto requiere un enfoque diferente para administrar el proyecto de lo que quizás digan los libros de texto. Necesitará cubrir las brechas y las limitaciones. Eso hará mucho más difícil el proceso en su conjunto.

Definir los Requerimientos de los Recursos

El primer paso es definir los requerimientos de recursos independientemente de las personas involucradas. Para hacer esto, cree una lista de roles y responsabilidades para el proyecto. No se restringa a las personas que tiene a su cargo, sino empiece desde la manera ideal en la cual se debería organizar el proyecto. A menudo es muy útil revisar proyectos anteriores para ver los roles y responsabilidades que existen.

Una vez que se tienen los roles y las responsabilidades enumerados, analice a las personas que han sido preasignadas para cumplir estos roles, y verifique como encajan. Al final tendrá un análisis de brechas respecto a:

· Recursos involucrados y las habilidades que aportan.
versus
· Los requerimientos de recursos para el proyecto.

Relacione las Habilidades de los Recursos

También verifique los recursos disponibles y las habilidades individuales que poseen. Podría ser posible redistribuir las responsabilidades para adecuarlas a personas específicas. Recuerdo un proyecto donde un asistente de negocios junior tenía la reputación de ser un excelente documentador. Cambiamos algunas responsabilidades para colocar mayores responsabilidades de documentación sobre esta persona. De esta manera se liberó a otros miembros del equipo para enfocarlos en el desarrollo de requerimientos antes que en la documentación final.

Las Brechas en los Recursos

A estas alturas deberíamos tener una idea clara de donde se encuentran las brechas de los recursos. El primer punto en la agenda es discutir el problema con el Patrocinador o con el Comité de Dirección del Proyecto. Esto podría ser suficiente para convencerlos de cambiar la asignación de los recursos del proyecto.

Caso contrario, habrá que hacer planes para cubrir las brechas. He aquí algunas estrategias:

Recursos a Tiempo Parciales

Busque personas que tengan las habilidades requeridas y vea si pueden ser asignados a tiempo parciales. Por ejemplo, si carece de recursos con conocimiento detallado de los procesos de un área en particular, vea si puede tener una persona asignada por un día o dos para llenar la brecha.

Recursos Externos

Quizás haya personas que no pertenecen a la compañía, que podrían ayudar en algunas áreas en particular. Por ejemplo si carece de alguien con experiencia en gestión de riesgos, hay numerosos elementos disponibles en el mercado que podrían llevar a cabo un asesoramiento en ese tema.

Preparar Recursos

Otra solución podría ser entrenar algunas personas para cubrir la brecha. Por ejemplo si necesita usuarios para desarrollar casos de uso para los requerimientos, y no tienen conocimientos de este tema, un programa de entrenamiento podría ser la solución.

Buscar otro Modo

La respuesta puede ser hacer las cosas de modo diferente. Por ejemplo, si está buscando implementar un paquete de software, pero carece de recursos de desarrollo, tal vez la mejor solución sea tercerizar la gestión del paquete. Busque un ASP (Application Service Provider) que se encargará del software y el hardware.

Financiamiento Alternativo

Si las restricciones de recursos son el resultado de una decisión de financiamiento, tal vez exista otra manera de financiar el recurso. Por ejemplo, si el proyecto no tiene las habilidades de testing necesarias, tal vez los servicios de un especialista en testing podrían ser financiados por el presupuesto operativo de algún otro departamento o incluso de algún otro proyecto.

Restringir la Actividad

Quizás posea un gran número de desarrolladores con experiencia en VB y está buscando soluciones que impliquen tanto VB como Delphi. Un método podría serrestringir la selección de la actividad no considerando el desarrollo en Delphi.

Identificar el Impacto

La mayoría de las soluciones esquematizadas anteriormente tendrán un impacto en el proyecto. Podría ser el costo, podría ser el tiempo, podría ser el alcance de la solución propuesta. Cada uno de los impactos debería ser documentado y aprobado formalmente por el Patrocinador y el Comité de Dirección. Si la organización decide limitar los recursos y las habilidades que provee, también debería estar preparada para aceptar las limitaciones del proyecto que podrían surgir de su propia decisión.

Evaluar las Personalidades

Todo lo que hemos discutido está relacionado con las habilidades de los recursos. Sin embargo también hay que considerar el aspecto de qué tan bien el equipo trabajará en su conjunto. Una vez me pidieron reclutar a dos personas que tenían un largo historial de no ser capaces de trabajar juntos. Era improbable que algo mágico fuera a pasar sólo porque estaban en el mismo proyecto. El patrocinador estaba entercado en que ellos necesitaban trabajar juntos para el éxito del proyecto.

Mi solución fue lograr que el Patrocinador les comunicara que yo tenía el poder para recomendarle que ambos fuesen despedidos si la situación llegaba a ser imposible para trabajar en equipo y lograr los objetivos del proyecto. En efecto, si llegaban a una situación en donde no podían trabajar juntos, se les pediría a ambos que dejaran la compañía, independientemente de quien estuvo bien o mal.

Los siguientes meses estuvieron lejos de ser fáciles y utilicé mucho tiempo trabajando directamente con las dos personas. Cada vez que tenían que trabajar directamente juntos, intentaba estar presente. Algunas veces estuvimos cerca de rendirnos, pero permanecía recordándoles que era una situación “perder-perder”. Si ambos no podían trabajar juntos, ambos terminarían sin empleo. Finalmente, se logró hacerlos trabajar durante todo el proyecto.

Resumen

La gestión de recursos del proyecto es una tarea compleja que usualmente no es tratada con la importancia que se merece. Es usual que se asignen personas y se tenga que proseguir el trabajo con ellas. A pesar de eso es necesario identificar las brechas en las habilidades de los recursos y tomar acción para cubrirlas.

No sólo hay que enfocarse en las habilidades requeridas del recurso. Adicionalmente hay que obtener indicios sobre temas personales y tratar de no ignorar lo que es obvio. Si dos personas no pueden trabajar juntas en un ambiente normal, probablemente tampoco podrán trabajar juntas en un ambiente de proyecto, de alta presión.

Finalmente, no hay que limitarse a aceptar recursos e ignorar lo que el proyecto necesita en términos de roles y responsabilidades. Si una responsabilidad no está asignada, en algún momento, esto se manifestará como un problema. Abordar esto tempranamente durante el ciclo de vida del proyecto evitará o reducirá el impacto.

CRÉDITOS

Autor: Neville Turbit

E-mail: project@projectperfect.com.au

Fuente: Project Perfect

Enlace artículo original: http://www.projectperfect.com.au/downloads/Info/info_project_resources.pdf

Contrato EPC vs EPCM ¿Cuál es mejor?


Durante mucho tiempo pareció que la manera más adecuada para organizaciones o Propietarios que emprendían importantes proyectos de construcción que requerían fuertes inversiones o financiamiento bancario, era optar por contratos a precio fijo, suma alzada, llave en mano o EPC (ingeniería, adquisiciones y construcción, por sus siglas en inglés). Por esa ruta esperaban obtener el grado de certeza en cuanto a tiempo y costos que requerían.

En un contrato EPC (ingeniería de detalle, compras, construcción), el contratista de construcción no solo construye sino que además, desarrolla la ingeniería de detalles y realiza las compras.

Si bien es cierto que la opción EPC a suma alzada en general sigue siendo la alternativa contractual más apreciada y exigida por Propietarios y financistas, en los últimos años ha habido un incremento de Contratistas que han preferido y a veces exigido contratos a costos reembolsables (precio base más un mecanismo de premio/castigo). Aunque este método de contratación no es poco común en el sector minero, el uso de los contratos EPCM se ha vuelto cada vez más frecuente en grandes proyectos de infraestructura y de construcción.

Al parecer el significado de EPCM (en comparación con EPC) sigue siendo relativamente desconocido en el ámbito de la construcción. La confusión fundamental estriba en que si bien la “C” en “EPCM” significa “construcción”, se refiere al contexto de “CM”, es decir, a la Gestión de la Construcción.

EPC vs EPCM

Comparativamente hablando en el modelo de contrato EPCM el Contratista realiza la ingeniería y la gestión de adquisiciones, y se limita a administrar la construcción a nombre del propietario. Es decir, el contratista EPCM no es quien construye; es el Agente del Propietario, creando (a nombre del propietario) relaciones contractuales directas entre el Propietario y los proveedores o contratistas comerciales. Cada contrato es un contrato de comercio directamente entre el Propietario y el Contratista o proveedor especializado de servicios. Es importante destacar que en este tipo de acuerdo se requiere que el Propietario cuente con un equipo de gestión de proyectos propio lo suficientemente grande y con experiencia, para ayudar al contratista EPCM con la gestión y administración de dichos contratos.

Ventajas de un contrato EPC desde el punto de vista del Propietario: El Contratista asume la total responsabilidad respecto a lo siguiente:

-Costo de finalización si es una suma alzada (sujeto a ajustes limitados)
-Plazo de término (sujeto a extensiones de tiempo)
-Calidad de diseño y construcción y logro de desempeño (sujeto a exclusiones)
-Implica que el potencial de múltiples disputas es evitado

Desventaja para el Propietario respecto al contrato EPC: la ingeniería de detalle es prerrogativa del contratista.

Ventajas de un contrato EPCM respecto del Propietario:

-La ingeniería de detalles atiende de mejor manera los estándares del proyecto
-La ingeniería de detalles está orientada a la construcción
-Todos los equipos cumplirían los estándares y requerimientos de servicio
-Es un contrato más barato ya que las contingencias las administra el Propietario
-Las garantías operacionales se obtienen igualmente de los proveedores de equipos
-El riesgo lo toma el contratista EPC, por lo tanto, incorpora contingencias al costo.

Desventaja para el Propietario respecto al contrato EPCM:

-La ingeniería de detalles busca fuertemente minimizar las cantidades de obras
-El dueño tiene poca influencia en la implementación del proyecto -Los equipos no 100% especificados tienden a ser seleccionados por su costo
-Obliga a tener un equipo parcial con algunas funciones tipo EPCM: control de calidad, programación y control, manejo de órdenes de cambio, seguridad, etc.
-Los Riesgos son muy difíciles de tomar por un Contratista

La decisión de optar por una u otra alternativa dependerá del análisis de una serie de factores, tales como:

-Optimización del Plazo
-Minimización de la Organización del Mandante
-Responsabilidad Técnica por la totalidad del Proyecto
-Fluidez de Gestión Propietario-Contratista
-Exposición al Riesgo-Situación del Mercado
-Mejor utilización de la especialización
-Minimización de Interferencias-Optimización del Costo
-Flexibilidad ante los Cambios en el Proyecto

Finalmente, recordemos que en toda negociación debe primar el equilibrio. El mejor contrato será aquel que permita al Propietario obtener un producto de alta calidad pagando el mínimo precio que satisfaga las justas expectativas y esfuerzo del Contratista.


Jaime Videla, PMP

Autor
Santiago, Chile


Jaime Videla, PMP, es autor de los libros “Los 7 pasos para salvar un Proyecto” y “20 trucos que debe conocer todo Contratista” Es editor del blog PMOChile, con más de 300 seguidores, donde ha publicado diversos artículos, fundamentalmente  relativos a la gestión de proyectos. Es socio y director ejecutivo de Videla Consultores EIRL, empresa que se especializa en consultorías y gestión de proyectos. Es socio de AccuFast! Cubicaciones, una empresa que ofrece servicios de cubicaciones y presupuestos. Desde 2010 es corresponsal internacional de la revista especializada PM World Today

Trabajó como Gerente Senior de Proyectos en Siemens, y Senior Project Manager de ABB, entre otras empresas top 200 según Forbes®. Tiene 25 años de experiencia en gestión de proyectos EPC y EPCM, mineros, industriales y eléctricos que sumados ascienden a más de US$212 millones. Se ha desempeñado profesionalmente en Argentina, Perú, Brasil, Chile, México y Alemania. En el año 2010 fue Director y Vicepresidente de Comunicaciones y Publicidad del PMI Santiago Chile Chapter. Ha sido un miembro activo del Project Management Institute (PMI ®) desde el año 2006 y recibió su certificación profesional como Project Management Professional (PMP ®) en 2007. También ha sido instructor de cursos de gestión de proyectos de RMC Project Management® a través de su representante chileno, y para el PMI Santiago Chile Chapter, entre otras importantes empresas. Jaime tiene estudios formales en Ingeniería Civil de la Universidad de Chile (1980).

Sus áreas de la actividad de hoy incluyen la consultoría, desarrollo e implementación  de PMOs, reclamaciones (claims), gestión de riesgos, coaching y la formación en gestión de proyectos (incluida la preparación del examen PMP). Además, trabaja como voluntario en la Fundación Trascender, una institución innovadora que gestiona una red de profesionales voluntarios a través de proyectos sociales. Jaime Videla habla con fluidez inglés y español, y comprende y habla portugués; vive en Santiago y puede ser contactado en 


Cree su Metodología basada en un Marco Estándar (1)


Este artículo, el primero de una serie de tres, provee algunos tips para diseñar e implementar una metodología basada en un marco estándar tal como ITIL o Guía del PMBoK®.

Muy bien, entonces ya ha decidido que su organización tiene que mejorar el modo en el que trabaja. Ha escogido la implementación de una metodología como el mejor camino para alcanzar este objetivo. Entonces se preguntará, ¿Por donde empiezo?

Cualquiera sea la disciplina que esté tratando de modelar (desde desarrollo de software hasta la gestión de la cadena de abastecimiento), es muy probable que exista un marco estándar para ello, que pueda servir como base para su propia metodología.

¿Qué es un marco estándar?

Un marco estándar es un conjunto de mejores prácticas, expresadas normalmente como un grupo de procesos repetitivos, creados por una organización (una asociación profesional, universidad, administración pública, etc.)

Estos marcos son algunas veces referidos como cuerpos de conocimiento, metodologías, etc. Los marcos estándares no pueden ser aplicados directamente. Estos apuntan a un amplio espectro de organizaciones, y por lo tanto no pueden ser detallados hasta un nivel en el cual están listos para ser usados. A fin de tener un conjunto de procesos ejecutables, se debe emprender un proyecto para llenar la brecha entre el marco de mejores prácticas y su metodología de procesos ejecutables. Este vacío se cubre cuando ha trasladado las mejores prácticas en procedimientos y políticas concretas, que toman en cuenta las características de su organización y su ambiente.

Por ejemplo, cuando el marco dice: “determine que riesgos pueden afectar al proyecto y
documente sus características” la metodología puede decir “el líder de proyecto registrará
todos los riesgos del proyecto en la lista de riesgos y documentará sus características”. La metodología también podría proveer una conexión a una hoja de cálculo que se usa como una plantilla para la lista de riesgos, y una descripción del rol del líder de proyecto en la organización (habilidades requeridas, experiencia mínima, etc.)

Metodología

Algunos de los marcos existentes que pueden ser usados como base para una metodología son los siguientes:

Gestión de Servicios TI: ITIL/COBIT/MOF
Gestión de Proyectos : Guía del PMBoK®/ PRINCE2
Desarrollo de Software: RUP/OPEN Process Framework
Etc.
Beneficios de usar un Marco Estándar

Puede beneficiarse del trabajo hecho por profesionales experimentados en el campo.
Establece una terminología estándar, que mejora la comunicación tanto externa como interna.
Facilita el proceso de benchmarking, por lo tanto conocerá que tan bueno es su desempeño en comparación con otras organizaciones.
Los proveedores de software crean productos compatibles con el marco, por lo tanto estará en capacidad de encontrar el software que automatice sus procesos apropiadamente.
Sus empleados estarán motivados, pues aprenderán cosas que aumentarán el valor de su profesionalismo.
La corriente principal de los marcos evolucionan en el tiempo, por lo que estará en capacidad de mejorar su metodología.
¿Qué Marco deberé escoger?

Se deberán tener en cuenta las siguientes recomendaciones al momento de escoger un marco:

Buscar e investigar. Es normal que existan varios marcos para una misma disciplina.
Determinar que estándar es el que mejor satisface sus necesidades en términos de la industria, del tamaño de la organización, etc.
Determinar como se integra el estándar con estándares de otras disciplinas.
Evaluar la estructura del marco. ¿Tiene una estructura y formato uniforme para todas las descripciones de procesos? ¿Describe los roles consistentemente?
Evaluar el alcance. ¿Contiene todos los procesos que necesitamos describir? ¿Hace referencia a sistemas de soporte? ¿Contiene guías directivas y plantillas?
Evaluar la correspondencia con las características de su compañía. Podría encontrar que algún estándar sea demasiado recargado para sus necesidades. Habiendo dicho esto, también hay que anotar que algunos procesos que lucen muy complejos en el marco pueden ser implementados a través de procesos muy simples que inserten las mejores prácticas de mayor valor añadido.
Sugerencias

Implemente los procesos gradualmente, empezando con aquellos que demuestran mayor valor.
Escoja un marco reconocido y usado por un gran número de organizaciones.
Elija un marco que formule un Modelo de Madurez de Capacidades. De esta manera tendrá un mapa y obtendrá visibilidad de hacia donde quiere llegar.
Lucas Rodríguez Cervera es fundador de Nevant – Process documentation software una compañía especializada en producir soluciones de procesos para compañías basadas en el conocimiento. Ellos fueron pioneros de este concepto con metoCube.

CRÉDITOS

Autor: Lucas Rodríguez Cervera

E-mail: info@nevant.com

Fuente: NEVANT

Enlace artículo original: http://www.crud.info/crud/create-your-methodology-based-a2516.html

Cree su Metodología basada en un Marco Estándar (2)

Este artículo, el segundo de una serie de tres, provee algunos tips para adaptar y documentar una metodología basada en un marco estándar tal como ITIL o PMBoK®.

En el artículo previo se explicó porqué era una buena idea el crear una metodología basada enun marco estándar, y se resaltaron los criterios para elegir el marco más conveniente. En este artículo daremos algunos tips para la adaptación y documentación de la metodología.

Entender el Marco

Una vez que se ha seleccionado el marco es tiempo de empezar a construir la metodología. El primer paso es adquirir una comprensión general del marco, una vista holística de sus componentes. Se debe tener una idea clara del alcance y límites. Podría ser útil (si ya se tienen algunos procesos formales implantados) mapear los procesos contra el estándar y ejecutar un análisis de brechas. Esto no es necesario si el enfoque del proyecto es el de un proyecto de reingeniería, en el cual se construyen los procesos desde cero.

Elaborar un Mapa

Una vez que se tiene una visión clara del alcance del marco estándar y de la situación actual, se debe definir adonde se desea llegar (el alcance de la metodología). Esto significa que se debe tener una visión clara de la organización una vez que la nueva metodología esté en operación. Se podría encontrar que algunos procesos no aplican a la organización o son demasiados sofisticados para sus necesidades.

Hay que ser realistas. Hay que considerar los recursos que están disponibles para el proyecto y los límites de tiempo. Hay que asegurarse que esta visión estratégica es conocida por todas las personas involucradas en el proyecto, y es entendida y compartida por el sponsor.

Ahora que se sabe adonde se quiere llegar y se han definido los objetivos del proyecto, es
tiempo de planificar cómo se llegará allí. El proyecto se puede enfrentar de dos maneras:

Entrega de una sola vez. La metodología solo se desplegará cuando se haya completado el alcance total.
Entrega incremental. La metodología se desplegará en varias iteraciones, cada una de las cuales liberará un conjunto de procesos.
Aunque el enfoque de una sola entrega puede ser más razonable cuando el alcance es limitado, un enfoque iterativo incrementa la posibilidad de éxito del proyecto. Hay que tratar de lograr éxitos rápidos escogiendo para las primeras iteraciones aquellos procesos que añaden valor visible o solucionan problemas conocidos. De este modo aprenderá con cada versión y aplicará ese conocimiento a las subsecuentes iteraciones.

Adapte y detalle los procesos

Los marcos estándares son de propósito general. Para poder ser útiles a un amplio y heterogéneo conjunto de organizaciones, los marcos proveen mejores prácticas expresadas en términos generales. Es su tarea convertir eso en piezas de trabajo operativas. Después de entender el proceso tal como es descrito en el marco, se tendrá que determinar cómo se desea ejecutarlo en el contexto de la organización, determinar los roles que serán responsables de ejecutarlo, las herramientas que se usarán para facilitar el trabajo, y los documentos, información, objetos, etc. que se deben producir.

Documente los procesos

Una vez que los procesos están claros, se deben documentar para facilitar la comunicación con las personas que los ejecutarán. El objetivo ahora es que el proceso se ejecute en el mundo real de acuerdo a la nueva definición del proceso. Esto sólo se puede lograr a través del entendimiento y el compromiso de las personas que ejecutarán los procesos, para esto una pieza clave es tener una buena documentación.

Los procesos se pueden documentar con una amplia variedad de formatos y herramientas (desde MS Word hasta metoCube, una herramienta de documentación de procesos desarrollada en Nevant). Cualesquiera que sea el formato y estructura seleccionada para la documentación de los procesos, siempre trate de tener en cuenta lo siguiente:

Los documentos de procesos siempre deben estar accesibles fácilmente. Si esto no es así, las personas no perderán tiempo buscándolos.
La documentación de procesos debe ser fácilmente navegable. Si las personas no encuentran rápidamente la pieza concreta de información que están buscando, probablemente desistirán o perderán tiempo valioso.
Las herramientas y plantillas necesarias para llevar a cabo el trabajo descrito deben ser fácilmente accesibles desde la documentación.
Complementar las descripciones textuales de los procesos con diagramas.

Lucas Rodríguez Cervera es fundador de Nevant – Process documentation software una compañía especializada en producir soluciones de procesos para compañías basadas en el conocimiento. Ellos fueron pioneros de este concepto con metoCube.

CRÉDITOS

Autor: Lucas Rodríguez Cervera

E-mail: info@nevant.com

Fuente: NEVANT


Gestión de los Riesgos del Programa


Gobierno de Portafolio


Procesos de Certificación (PMI- RMP)


Introducción a los procesos de la gestón de Riesgos del Proyecto


GPY051 – Planificar la Gestión de Riesgos


GPY051 – Identificar los Riesgos


Curso Taller de Preparación para la Certificación (PMI- RMP)®- Realizar el análisis cualitativo de Riesgos


Taller de Preparación para la Certificación (PMI-RMP)® – Realizar el Análisis Cuantitativo de Riesgos


Comunicación y Gobierno de los Riesgos


Motivación en la Gestión de Proyectos


Taller de MS Project 2010 para la Gestión de Proyectos – Sesión 03


Taller de MS Project 2010 para la Gestión de Proyectos – Sesión 04


Taller de MS Project 2010 para la Gestión de Proyectos – Sesión 05


Taller de MS Project 2010 para la Gestión de Proyectos – Sesión 07


Taller de MS Project 2010 para la Gestión de Proyectos – Sesión 08


Curso Herramientas Avanzadas para la Gestión de Proyectos – Sesión 03


Curso Gestión de Portafolios – Sesión 01


jueves, 6 de abril de 2017

Control y Análisis EVM



PRESENTACIÓN

En el presente Tip se explicará como realizar el Control del Proyecto, y veremos la evolución del proyecto según el análisis EVM.

CONTENIDO



1.- Revisión de la Configuración

            1.1.- Revisión de las Estadísticas

            1.2.- Revisión de la Carga de Trabajo de Recursos

 2.- Metodología de Carga de datos

 3.- Control Semana 5

 4.- Informe de Performance del Periodo



1.- REVISIÓN DE LA CONFIGURACIÓN

 No debemos olvidar revisar la configuración del proyecto, cada vez que realicemos alguna modificación o actualización en el proyecto.



1.1.- Revisión de las estadísticas

También es importante revisar la fecha de inicio del proyecto y sus estadísticas, pues así verificamos los datos macro del proyecto, los cuales son: Duración Total, Costo Total, y Trabajo Total. Para revisar las Estadísticas realizaremos los siguientes pasos:


1.2.- Revisión de la Carga de Trabajo de Recursos

Ahora también debemos verificar como está distribuida la carga de trabajo en el proyecto, para lo cual es necesario emitir un informe de Uso de Recursos, donde se observe el estado previsto del trabajo de los recursos a lo largo del proyecto.

Para emitir un Informe de Uso de Recursos realizaremos los siguientes pasos:


Con el Informe de Uso de Recursos, podemos verificar cual es la carga de trabajo que han venido realizando los recursos en el desarrollo del proyecto.



2.- METODOLOGÍA DE CARGA DE DATOS

Para un mejor control del avance del proyecto se sugiere seguir la siguiente metodología, debido a que se emitirán informes de avance semanal, es recomendable guardar archivos de los avances semanales (línea base, informes, etc.) en una carpeta separada, como apreciamos en la siguiente gráfica.

Dentro de cada carpeta se deberá guardar los archivos correspondientes a la semana indicada:



3.- CONTROL SEMANA 5

Para el control de la semana 5 debemos realizar los siguientes pasos:

Las tareas que se desarrollan en la semana 5 son las que se observan en la gráfica siguiente:



Como observamos en la gráfica siguiente se ha configurado la tabla para poder ingresar los datos reales del trabajo.



Ingresamos los siguientes datos:



Cuando se ingresa el dato de  trabajo real de 8 horas para el lunes 29 de  enero,  el mismo Project modifica y redistribuye las horas que han sido asignadas a la tarea.

Se deberá cargar la siguiente información:



Como podemos observar los recursos asignados a la tarea 2.2.A01 han sido ampliados hasta la siguiente semana.

¿Se modifica la línea base con esto?

La línea Base NO se modifica, pues la información de la línea Base es fija, mientras que los datos de trabajo que estamos ingresando son datos de modelamiento.

4.- INFORME DE PERFORMANCE DEL PERIODO

Para elaborar el Informe de Performance del Periodo, debemos realizar los siguientes pasos:


La vista de nuestra nueva tabla llamada Valor Ganado, es la siguiente:



En la siguiente tabla apreciamos el estado total del proyecto, resumida en sólo 2 niveles. La fecha de estado actual del proyecto es 27 de enero.



Con la información de la tabla anterior, podemos emitir la Curva S, que apreciamos a continuación: