Web Proyectics

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

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.