- Gestión de competencias
- Sistemas para la Gestión de Proyectos
- Estructuras Organizacionales que permitan una buena gestión de proyectos programas y portafolios.
- Asingación de recursos adecuados a los proyectos
- Alineamiento estratégico
- Asignación de "sponsors" a los proyectos , programas y portafolios
- Existencia de Métricas para la Gestión de Proyectos
- Programas de Entrenamiento en Gestión de Proyectos
- Criterios de éxito definidos en los proyectos
- Una Metodología para la gestión de proyectos, programas y portafolios
- Una Visión y Política para la OPM (Organizational Project Management)
- Prácticas de OPM
- Técnicas para OPM
- Sistema de Información y de gestión del conocimiento relativas a OPM
- Evaluaciones de desempeño
- Comunidades de OPM
martes, 17 de noviembre de 2009
Los "Posibilitadores Organizacionales" en el OPM3

lunes, 26 de octubre de 2009
Liderazgo

jueves, 22 de octubre de 2009
Congreso PMI Lima Peru 2009
Agenda del Evento - *Octubre 29 | ||||||||||
Hora Inicio | Hora Fin | Actividad | ||||||||
08:00 | 09:00 | Registro de participantes. | ||||||||
09:00 | 09:20 | Discurso de bienvenida del inicio del Tour - Mentor de la Región 13 de Sudamérica del PMI, Victor Villar, MBA, PMP | ||||||||
09:20 | 09:30 | Discurso de bienvenida - Presidente del PMI Lima, Perú Chapter, Alfonso Núñez, MBA, PMP | ||||||||
TRACK A | TRACK B | TRACK C | ||||||||
09:30 | 10:20 | Presentación de impacto: PMI President & CEO, Gregory Balestrero, USA. Tema: "Proving the Value of Project Management in a Troubled Economy". | ||||||||
10:20 | 11:10 |
|
|
| ||||||
11:10 | 11:40 | Cofee Break | Cofee Break | Cofee Break | ||||||
11:40 | 12:30 |
|
|
| ||||||
12:30 | 13:20 |
|
|
| ||||||
13:20 | 15:00 | Almuerzo | Almuerzo | Almuerzo | ||||||
15:00 | 15:50 |
|
|
| ||||||
15:50 | 16:40 |
|
|
| ||||||
16:40 | 17:10 | Cofee Break | Cofee Break | Cofee Break | ||||||
17:10 | 18:00 |
|
|
| ||||||
18:00 | 18:15 | Cierre del día 1 - Presidente del PMI Lima, Perú Chapter, Alfonso Núñez, MBA, PMP | ||||||||
Número de conferencias: 19 (incluyendo: Presentación de impacto) | ||||||||||
Duración del Cofee Break: 30 min | ||||||||||
Duración del almuerzo: 1h 40 min |
Agenda del Evento - *Octubre 30 | ||||||||||
Hora Inicio | Hora Fin | Actividad | ||||||||
08:00 | 09:00 | Registro de participantes. | ||||||||
TRACK A | TRACK B | TRACK C | ||||||||
09:00 | 09:50 |
|
|
| ||||||
09:50 | 10:40 |
|
|
| ||||||
10:40 | 11:10 | Cofee Break | Cofee Break | Cofee Break | ||||||
11:10 | 12:00 |
|
|
| ||||||
12:00 | 12:50 |
|
|
| ||||||
12:50 | 14:30 | Almuerzo | Almuerzo | Almuerzo | ||||||
14:30 | 15:20 |
|
|
| ||||||
15:20 | 16:10 |
|
|
| ||||||
16:10 | 16:40 | Cofee Break | Cofee Break | Cofee Break | ||||||
16:40 | 17:30 | Conferencia magistral - Líder de Negocios y/o de Gobierno. | ||||||||
17:30 | 17:50 | Premiación al Proyecto del Año | ||||||||
17:50 | 18:00 | Discurso de cierre - Presidente del PMI Lima, Perú Chapter, Alfonso Núñez, MBA, PMP. | ||||||||
18:00 | 18:50 | Evento de cierre - Show y Pisco de honor. | ||||||||
18:50 | 20:00 | Cierre del día 2. | ||||||||
Número de conferencias: 19 (incluyendo: Conferencia magistral) | ||||||||||
Duración del Cofee Break: 30 min | ||||||||||
Duración del almuerzo: 1h 40 min |

jueves, 20 de agosto de 2009
Plan de Gestión de Proyectos - PMBOK(r) Cuarta Edición

jueves, 18 de junio de 2009
Proyecto del Año PMI Lima Peru
PREMIO AL PROYECTO DEL AÑO
Debido al gran crecimiento de empresas y proyectos en nuestro país y preocupados por los manejos de los nuevos capitales provenientes de los tratados internacionales firmados o próximos a firmarse, el Chapter PMI LIMA PERU está organizando un concurso denominado el “Premio al Proyecto del Año”, esta iniciativa nace con el propósito de impulsar y de reconocer la contribución de las empresas en el campo de la Gestión de Proyectos durante los primeros 10 años de creación del Chapter PMI LIMA PERU.
Mediante esta iniciativa el Project Management Institute (PMI) representado por el Chapter PMI LIMA PERU busca fortalecer las buenas prácticas en la gestión de proyectos.
Con este propósito se desea que las empresas que quieren satisfacer alguna necesidad (interna o externa a la empresa) mediante la ejecución de uno o más proyectos, éstos sean planificados de manera adecuada y se puedan ejecutar correctamente bajo un apropiado control y seguimiento para finalmente cerrar el proyecto exitosamente y obtener las lecciones aprendidas que puedan ser utilizadas en proyectos futuros, según el estándar de las buenas practicas difundidas por el PMI.
BASES DEL CONCURSO
Las bases del concurso están acorde al Estándar del PMI para Premios. Se adjuntan las Bases del Proyecto del Año, mayor información Descarga las Bases del Concurso.
HITOS DEL PREMIO AL PROYECTO DEL AÑO
Hito | Fecha |
Inicio de la convocatoria. | 12/06/2009 |
Fecha Final de Recepción de consultas. | 19/06/2009 |
Absolución de consultas. | 26/06/2009 |
Fecha Final de Recepción de postulaciones. | 15/09/2009 |
Fecha Final de Evaluación | 15/10/2009 |
Ceremonia de premiación | 30/10/2009 |
COMITÉ DE EVALUACION
El Comité de Evaluación está compuesto por los Past-Presidents y los Past-Components del Capítulo del PMI Perú, que cumplan con los requisitos mínimos establecidos en las bases, y de no tener impedimento alguno, llevarán a cabo de manera equitativa y transparente este proceso, basados en su experiencia e idoneidad.
Esperamos sus consultas y sugerencias a las bases.
Atentamente
Ing. Alida Anicama Cubas, MSc, PMP
Vicepresidenta de Proyectos Especiales
alida.anicama@pmi.org.pe
PMI Lima Perú Chapter
Organiza: PMI LIMA PERU CHAPTER

martes, 16 de junio de 2009
Consejos para Tratar las Tensiones en el Equipo del Proyecto
El último número (Volume 4, Issue 3) de la publicación PMP(r) Passport describe unos consejos para tratar las tensiones en el equipo del proyecto.
No hay nada peor que un ambiente estresado en un proyecto para amplificar las diferencias de personalidad y convertirlas en tensiones en el equipo y hasta en conflictos.
Los proyectos pueden muchas veces llevar a sus equipos a niveles altos de estrés, hasta cuando las cosas van bien, y los miembros del equipo tendrán algunos roces seguramente. Algunos podrán perder los estribos. Los Egos se sentirán heridos.
El antídoto para este posible problema en la productividad es definir lo antes posible las expectativas-- y tratar rápidamente los problemas generados por la tensión.
Aquí mostramos algunos consejos de los expertos para tratar los conflictos y mantener a tu equipo (y al proyecto) en el camino adecuado.
Antes que se iniciar el proyecto
Consejo 1. Defina el "tono" desde el inicio.
Las diferencias en expectativas y las malas comunicaciones generan la mayor parte de los conflictos.
Como gerente de proyectos, usted debe fomentar que su equipo contribuya al plan de gestión del proyecto antes que el proyecto inicie, lo que también, define expectativas claras.
Asegúrese que los miembros del equipo del proyecto entienden claramente --y están de acuerdo-- con los parámetros del proyecto en cómo dichos parámetros calzan con el alcance del proyecto.
Aclare los roles de los miembros del equipo del proyecto para que cada persona entienda en que pueden contribuir al proyecto. Esto también confirma lo que se espera de ellos y les permite planificar y priorizar sus responsabilidades para que el proyecto mantenga el curso.
Si aparecen conflictos.
Consejo 2. Mangéngase imparcial.
Los líderes de los proyectos no deben tomar partidos. Si un miembro del equipo del proyecto se le acerca a usted con respecto a un conflicto, sea objetivo en su consejo para tratar la situación.
Usted podrá necesitar buscar a la otra parte involucrada y escuchar su descripción de la "historia". Esto le permetiriá a usted tener un mejor entendimiento de la situación y le permitirá generar una respuesta no sesgada hacia una de las partes.
Consejo 3. Sea un catalizador, no un solucionador de problemas.
La resolución es el resultado de la mediación desde abajo hacia arriba. Como líder del proyecto, usted asume el papel de facilitador. Usted ayuda a los miembros del equipo del proyecto a resolver conflictos; usted no los resuelve por ellos.
Después que usted identifique las fuentes de las tensiones y luego de escuchar los dos lados de la historia, proponga que el equipo se reuna. Invite a cada persona a presentar su perspectiva, y que la otra parte escuche sin responder.
Finalmente, fomente que los miembros del equipo lleguen a un consenso, trabajando hacia un objetivo común para resolver el conflicto y re-enfocarse en completar el proyecto. Este último paso puede incluir desarrollar un plan de acción con pequeñas actividades para llevarnos hacia la solución del conflicto.
Consejo 4. Se debe "escalar" progresivamente (poco a poco):
Si persisten los problemas entre los miembros del equipo, usted podría requerir ir más arriba en la cadena de mando para ayudar a resolver el tema. El hablar con los supervisores funcionales o los gerentes puede también generar ideas acerca del origen de las tensiones.
Si los supervisores funcionales no ayudan a facilitar la solución, ustede debería escalar progresivamente la situación en la cadena de mando hasta que encuentre a dos miembros de la organización que trabajarán en el conflicto.
Usted también puede considerar consultar a un experto externo en temas de empresa o recursos humanos. Este experto, que no está involucrado con los miembros del equipo del proyecto o con el proyecto, provee al equipo un foro abierto para dicutir sobre las maneras más efectivas para trabajar juntos y también provee un análisis neutral de la situación.
Consejo 5. Métete y toma una decisión
Si todo lo demás falla, no tenga miedo de indicar una solución--especialmente si esto va a prevenir un desastre en el proyecto.
Como gerente de proyecto, su principal preocupación es hacer lo que es mejor para el proyecto y para el equipo. Si el conflicto continua y tiene un impacto negativo en su proyecto, imponga una solución que manendrá al proyecto en su camino.
Su solución podría involucrar el reemplazar a alguien en el equipo para que usted pueda lograr cumplir con una fecha de entrega.
Ona Vez que se ha resuelto el conflicto:
Consejo 6. Celebre el éxito
El reconocer que se ha resuelto un conflicto o simplemente agradeciendo a la gente por sus esfuerzos genera impactos tremendamente positivos en el ambiente del proyecto.
La gente responde de manera favorable a refuerzos positivos y a la retroalimentación positiva. Más aún, los miembros del equipo estarán más que dispuestos a sobreponer sus diferencias y a trabajar juntos si saben que se les va a reconocer.
Panel de Expertos:
Edna Campos, PMP, gerente de proyectos para IBM, Sao Paulo, Brasil y presidente del Capítulo del PMI de Bahía. La señora campos está concentrada en proyectos internacionales para IBM para la que gestiona equipos virtuales, donde la posibilidad de conflictos--sin interacciones cara a cara-- es un tema constante. (Contribuyó a los consejos 3, 4 y 5).
Nick Clements, PMP, dueño de la empresa consultora Analytic Risk Management, ubicada en Maryland, USA. Gran parte de su carrera ha estado gestionando grandes proyectos del sector gobierno en los Departamentos de Defensa y de Educación. (Contribuyó a los consejos 1, 2, 4 y 6).
Michelle LaBrosse, PMP, dueña de Cheetah Learning, empresa basada en Carson City, Nevada, USA. Cheetah Learning es un Registered Educational Provider del PMI. La Señora LaBrosse se eonfoca en un rango de proyectos desde proyectos a gran escala en temas de tecnología de la información con equipos de 20 personas, hasta esfuerzos pequeños para desarrollar cursos, que involucran entre 3 y 5 personas. (Contribuyó con los consejos 1 y 5).

martes, 9 de junio de 2009
Requerimientos

La definición de los entregables del proyecto tiene como pre requisito la definición de los requerimientos. El IIBA publicó un resúmen de un artículo de Alex Paperworth publicado en www.bamentor.com, donde Paperworth sugiere definir atributos obligatorios y atributos opcionales para la definición de los requerimientos.
Atributos Obligatorios:
- ID del Requerimientos. Un código único para cada requerimiento para poder realizar el seguimiento a lo largo del ciclo de vida del proyecto.
- Prioridad. Se puede usar una escala del 1 al 5, o si se desea usar términos descriptivos tales como: bajo, medio, alto y crítico.
- Dueño o responsable. El interesado con la autoridad para aprobar un requerimiento. Este punto es muy importante en el proceso de control integrado de los cambios.
- Fuente. Es el nombre del interesado que expresó o describió el requerimiento. La fuente no necesariamente tiene que ser el dueño del riesgo.
Atributos opcionales:
- Estado. Por ejemplo: borrador, revisado, aprobado, rechazado, etc.
- Explicación. La razón por la cual existe el atributo. Posiblemente la explicación o la razón por la que existe el atributo pueda cambiar si es que cambian los objetivos del proyecto.
- Dependencia. Describe las relaciones de dependencia entre un requerimiento y otro. Sirven para mostrar de manera explícita los impactos que pueden tener los diferentes requerimientos.
- ID de Requerimiento Padre: Sirve para definir un árbol de requerimientos, es decir, para mostrar la estructura jerárquica de requerimientos.
- Categoría. Sirven para clasificar los requerimientos por su tipo: Ingeniería, Calidad, Legal, Medio Ambiente, etc.
Félix Valdez, PMP

martes, 2 de junio de 2009
Google Wave - Configuration Management to the Max???
Hace una semana Google ha anunciado "Google Waves": un cambio fundamental en el paradigma que usamos para comunicarnos.
Actualmente la comunicación sigue el paradigma de las comunicaciones físicas (usando sobres y cartas de papel): El emisor prepara un correo y dicho correo se envía a una serie de receptores.
El receptor puede recibir la comunicación y si la quiere re-enviar, puede escribir un mensaje nuevo, y copia el mensaje recibido anteriormente, pero cuando nos copian un mensaje a la mitad de una conversación, no sabemos si hemos leído toda la historia.
El cambio, entonces, se dá que en lugar de crear un mensaje y "enviarlo", se crea una "ola" o "wave", que es un documento que la persona coloca en un servidor (los servidores de Waves, se podrán comunicar entre sí, de manera similar a la de los correos electrónicos). Una vez creado el documento indicamos a las personas que tendrán acceso a dicho documento. Y cuando decimos acceso, este es un acceso en tiempo real. Es como si pegáramos una pizarra, y varias personas pudiesen escribir o borrar en tiempo real sobre la pizarra. Imaginémonos ésta metáfora aplicada para las comunicaciones. Cuánto tiempo perdemos en correos electrónicos que son una copia de la copia de la copia de la copia.... etc.?
Otra aplicación de Waves será la edición conjunta de documentos, como por ejemplo contratos. Imaginémonos a dos abogados colaborando en un documento, en tiempo real. Ah me olvidaba, una característica de los waves es que se puede ver la secuencia de cambios realizados en un documento, es decir la historia del documento, y dicha historia se podrá filtrar por usuario, o grupos de usuarios. Ejemplo: ver la evolución de un documento X, a través de los cambios que generó Juan.
Podríamos también hablar de crear documentos de diseño: 5 personas podrían trabajar a la vez en el dibujo de un plano para un edificio, y quedaría siempre un registro de los cambios.
La Guía para el PMBOK(r) viene mencionando hace un buen tiempo (desde el año 2000 por lo menos) la importancia de una buena gestión de la configuración, que en otras palabras tiene que ver con el manejo de las distintas versiones de los productos, servicios y resultados que se generan en los proyectos. Estos elementos pueden ser los entregables del proyecto o los entregables necesarios para la gestión del mismo (cronogramas, presupuestos, planes de respuestas a los riesgos, especificaciones de calidad, etc).
Entonces, el impacto en la gestión de proyectos va a ser inmensa ya que toda la problemática de la gestión de la configuración va a poder ser administrada como Waves.
Estemos alertas para el anuncio de esta nueva tecnología que promete cambiar radicalmente las vidas de los gerentes de proyectos, y de la población en general.
Me imagino colaboraciones ya no tan técnicas, sino en el ámbito más creativo: Waves para componer música? Waves para planificar una vacación? Waves para preparar el lanzamiento de un producto? las aplicaciones son infinitas.

miércoles, 15 de abril de 2009
Enlaces con la Organización y Gestión de Costos??
Cuál es el uso?
Imaginémonos que tenemos una empresa que produce y exporta pulpa para fabricar papel.
Los activos de la empresa los podríamos dividir de acuerdo a áreas físicas de la empresa:
1. Campo
1.1 Cultivo
1.2 Lavado y empaque de materia cultivada
1.3 Almacen en Campo
2. Carretera hacia fábrica
3. Fábrica
3.1 Almacen de Entrada
3.2 Area de Tratamiento
3.3 Almacén de Salida
4. Edificio Administrativo
5. Sistemas Organizacionales
Entonces, si, por ejemplo, la empresa desea realizar una mejora en los almacenes, que incluya la ampliación de almacenes y una mejora en los sistemas logísticos, podríamos definir un proyecto con los siguientes entregables:
A. Infraestructura
a.1 Diseños
a.2 Adquisición y Construcción
a.2.1 Equipos y Adecuación almacen de Entrada
a.2.2 Equipos y Adecuación almacen de Salida
a.2.3 Equipos y adecuación almacen Campo
a.3 Pruebas y Puesta en Marcha
B. Adecuación Sistema Logístico
b.1 Docuemento de Análisis aprobado
b.2 Documento de diseño aprobado
b.3 Software Desarrollado
b.4 Hardware Adecuado e Instalado
b.5 Pruebas de Solución Hardware Software
Entonces, todos los elmentos del Código B. Adecuación Sistema Logístico, que es uno de los entregables de la EDT, deberían de tener una relación con el elemento 5. Sistemas Organizacionales, para que al final del proyecto, los costos incurridos en el desarrollo del sistema, generen un cambio en el valor de los activos de la organización.
Generalmente esta conversión no afecta la gestión del proyecto, es simplemente un requerimiento de los clientes con el fin de tener un mejor control en los cambios en los valores de sus activos.

jueves, 26 de marzo de 2009
Etica y Proyectos - Herramientas
El día de ayer asistí al Foro Empresarial Anticorrupción, organizado por IPAE y ProEtica.
El foro se inició con una presentación de Cecilia Blondet, que preside el Consejo Directivo de Proetica. Proetica ha venido realizando encuestas anuales sobre la Corrupción. En la última encuesta, de fines de 2008, había un 43% de la población que tenía la sensación que la corrupción en el país iba a aumentar en los próximos 5 años (comparado con un 30% en el 2006).
Una de las principales causas que la gente atribuye a la corrupción en el país es la falta de liderazgo por parte del gobierno en la lucha contra la corrupción.
Luego tuvimos una presentación por parte de Claudio Herzka, Presidente de IPAE. Una de las reflexiones de Claudio Herzka fue que para si para que exista un gobierno corrupto tiene que existir una contraparte corruptora.
Se formaron varios grupos de trabajo con el fin de poder definir un plan de acción del sector empresarial con respecto a la corrupción.
Se plantearon varias ideas, y básicamente concluímos que es necesario trabajar en los campos de la Educación (desde la primaria), en sistemas que ayuden al ciudadano común a reportar incidentes de corrupción, pero además en que los líderes de las empresas tienen que tomar un rol activo en impulsar códigos de ética, programas de difusión, y además dar el ejemplo.
Etica y Proyectos - Herramientas
La pregunta, con respecto a los proyectos, qué podemos hacer? Cuál es el papel de los gerentes de proyecto con respecto a la corrupción?
El PMI ha publicado un Código de Etica, que es el código por el cual nos regimos todos los miembros del PMI.
Los gerentes de proyecto tienen un papel muy importante y los dueños (owners) de los proyectos tienen una gran responsabilidad. La corrupción en los proyectos de infraestructura se puede dar en distintas fases: al seleccionar al proyecto, conseguir financiamiento, ingeniería, construcción. Es necesario que el gerente de proyecto apoye a los dueños en el despliegue de una estrategia para minimizar la corrupción del ámbito del proyecto.
El Centro Golobal de Anti-Corrupción para Infraestructura (GIACC - Global Infrastructure Anti-Corruption Centre), ha publicado una plantilla para la implementación de un porgrama anti-corrupción.
El GIACC también tiene otras herramientas tales como:
- Código para Reclamos (Claims)
- Términos de Contratos
- Código
- Due Diligence
- Términos para empleo
- Política para regalos y "hospitalidad"
- Procura
- Reportes
- Reglas
- Entrenamiento
- Transparencia
