PMI Madrid Spain

Artículos

ABSTRACT

 El análisis de riesgos en los proyectos, dentro de la globalidad existente, es una herramienta necesaria y fundamental ante el actual mercado competitivo. Sin duda, esta clase de sucesos siempre ha existido y de una manera u otra se han tenido que afrontar.

Dada la complejidad de los proyectos, se ha de realizar una adecuada gestión que garantice un uso eficiente de los recursos. No solo es necesario plasmar una planificación estratégica de los portafolios o programas de las compañías, además se debe analizar cada proyecto de manera específica con independencia de su tipología y singularidad para desarrollar la identificación de los sucesos.

Implantar de manera defectuosa la gestión de riesgos, o no hacerla con las herramientas adecuadas, es una de las principales causas de fracaso de los proyectos.

Por todo esto, hay que llevar adelante una planificación estratégica de la organización como un conjunto de buenas intenciones; además, se deben desarrollar mecanismos que los plasmen en la práctica.

De estas necesidades se estableció una serie de metodologías, normas, buenas prácticas o estándares y sistemas de gestión de riesgos: PMI®, IPMA®, COSO®, ISO®, etc.

Si eres socio con una antigüedad de 5 años o más (a cumplirse a lo largo de este año 2019) puedes participar en el sorteo de una de las 20 entradas que regalamos para nuestro Congreso Anual del día 21 de Noviembre de 2019.

Escríbenos un mail a Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo. indicando en el asunto “SORTEO ENTRADAS CONGRESO”. En el cuerpo del mail escribe tu nombre completo y la dirección de mail que usas para tu perfil de PMI así como tu PMI ID. El PMI ID será el número que entrará en el sorteo. 

El próximo día 17 de Octubre, durante la III Reunión Anual de Voluntarios, y con todos los voluntarios como testigos, sortearemos las entradas entre todos aquellos que hayan solicitado participar en el Sorteo.

Si resultases ganador, además de conocer los números premiados a través de las Redes Sociales con el Hastag #PMI_MADRID_SORTEO, recibirás un mail con las instrucciones para puedas usar tu bono de acceso gratuito a nuestro Congreso Anual.

La fecha límite para participar es el 17 de octubre de 2019 hasta las 16:00H (hora peninsular).

SUERTE!!

Call for Papers

Los capítulos de Centroamérica invitan a participar en su evento "Administración de Proyectos 4.0" a celebrarse durante los días del 5 al 7 de noviembre en formato virtual y una actividad presencial de cierre el día 7 de noviembre en San José, Costa Rica, en streaming.

 

La invitación es tanto a participar como ponentes como de asistentes. 

 

Si están interesados pueden registrarse en: https://form.jotform.co/92086087644869 en donde también encontrarán material informativo.

 

Cualquier duda por favor comuníquese directamente conmigo el Equipo Regional APCON, Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.

 

Para más información del evento a partir del 8 de setiembre puede acceder a: http://apconregional.com/

 

chatbot

5 posiciones de voluntariado abiertas para socios y no socios, apúntate aquí:

 

En el equipo TIC de PMI Madrid estamos iniciando un proyecto para poder atender a los socios con mayor interactividad que por la web, a través de un chatbot por Slack, que podríamos llamar PMI Madrid Bot.

Buscamos voluntarios para programar este chatbot para que pueda usarse desde nuestro grupo de Slack.

¿Quieres participar o conoces a alguien interesado? Contactad por favor por email: Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo. 

dsdm

 

En un proyecto ágil se fija el tiempo que dispone la organización para conseguir los objetivos. No se calcula plazo estimando el tamaño de los requisitos, el trabajo que supondrían y lo que tardarían los recursos disponibles. No puede hacerse así porque no se conocen los requisitos en detalle suficiente. En lugar de calcular un plazo del proyecto, se toma este plazo como una restricción del negocio. Se hace una planificación inicial en la que se acaban sabiendo los requisitos de alto nivel, el plan de entregas, las restricciones de plazo, etc. Así planificamos inicialmente el cronograma y también el coste, pues un equipo continuo durante un plazo concreto tendrá un coste determinado.

Un proyecto de 12-24 meses, por ejemplo, suele dividirse en 4-6 fases de 3-4 meses cada una. Cada una de estas fases puede gestionar a su vez como un proyecto o fase, teniendo en cuenta los 49 procesos del PMBOK, si es preciso. En proyectos software, estas fases suelen denominarse "releases" porque tienen el objetivo de entregar a los usuarios finales una funcionalidad terminada. Al proceso de planificar una release se le denomina "release planning" y consiste en determinar en equipo las historias más importantes de la release y asegurarse de que se pueden entregar. Teniendo en cuenta la velocidad del equipo, que suele medirse en historias por iteración, puede calcularse el número de iteraciones, que deben tener una duración fija durante toda la release (concepto de time-box: las iteraciones ágiles siempre terminan en fecha, normalmente duran entre 1-4 semanas, pero si se decide 2 semanas, por ejemplo, esto no se debe cambiar hasta la siguiente release).

El alcance se va planificando en detalle a medida que la release avanza. El resultado del "release planning" suele denomiarse "release backlog", que es propiamente un subconjunto del "product backlog". Al principio de la release, en el release backlog tenemos historias muy grandes (deberían denominarse épicas, mejor que historias) y deben irse descomponiendo y refinando gradualmente. El Product Owner es el encargado de mantener refinada la planificación de las historias del release backlog, especialmente aquellas planificadas para la siguiente iteración. Las historias pueden cambiarse, los cambios son bienvenidos porque ocurren en el product backlog. No debe cambiarse, sin embargo, el trabajo que ha entrado en la iteración, en el que ya está trabajando el equipo de desarrollo.

En la ceremonia llamada iteration planning, el equipo de desarrollo planifica la iteración descomponiendo las historias en tareas que deben ir procesando para ser completadas antes de que finalice la iteración. Típicamente se usan tableros kanban con columnas to-do, doing, done, para visualizar cómo va el trabajo del equipo durante la iteración.

Cada día, en el daily standup, los miembros del equipo informan unos a otros de lo que han hecho desde el último daily, lo que se proponen hacer durante el día, y los impedimentos que les dificultan trabajar al ritmo que esperaban.

Es decir, en un proyecto agile, si se ejecuta siguiendo el marco Scrum, se planifica el día, la iteración (2 semanas), la release (3-4 meses), el proyecto (12-24 meses)...

La planificación suele quedar como reflejo fiel a los trabajos ejecutados, no hay scope creep, no hay padding, etc.

¿Podríamos decir que en un proyecto ágil, si se gestiona bien, se dedica más esfuerzo a planificar que en un proyecto predictivo?

  JoseBarato

Por Jose Barato, PMP, PMI-ACP, vocal de PMI-Madrid