Características de Proyectos de Software "disfuncionales"

En el artículo "Seven Characterístics of Dysfunctional Software Projects", se describen las siguientes características de proyectos de software "disfuncionales". Cuántos de estos elementos tiene actualmente su proyecto???:

1. No aplicar prácticas básicas de gestión de proyectos. Muchos proyectos con problemas no aplican técnicas básicas de gestión de proyectos tales como la preparación de estimados de costos, cronogramas, planificación de recursos, gestión de la configuración, y una gestión proactiva de los riesgos. Luego se preguntan por qué su proyecto tiene problemas constantemente...
2. Optimismo sin razón y unas expectativas irreales por parte de la alta gerencia. Algunas personas ven los temas como problemas "color de rosa" cuando en verdad son alarmas de color rojo que indican que hay problemas!.
3. No se implementan procesos efectivos para el desarrollo de software. Esto puede generar inconsistencias en los requerimientos y la capacidad del personal de implementarlos. Asímismo errores en la codificación que no se detectarán hasta muy tarde en el desarrollo.
4. Declaratorias prematuras de Victoria. Las presiones para entregar productos a tiempo muchas veces generan declaraciones prematuras de culminación por parte de los gerentes. El éxito no puede declararse hasta que los productos hayan sido terminados cumpliendo las condiciones contractuales de calidad y confiabilidad.
5. Falta de un Liderazgo por parte del Gerente de Programa. El gestionar un proyecto de software requiere de personas con coraje que están dispuestas a afrontar los retos de hoy y evitar las catástrofes de mañana. Hay dos tipos de problemas: personas con conocimiento de ingeniería de software pero sin experiencia en gestión, y aquellos que tienen experiencia en gestión y no tienen experiencia en ingeniería de software. Es necesario tener una mezcla adecuada de ambos temas.
6. Toma de decisiones en el momento equivocado. No se debe esperar a que sea muy tarde para tomar decisiones.
7. Falta de una Gestión de Riesgos Proactiva. "Lo que distingue a las mejores organizaciones y a los mejores gerentes no es solamente cuan bien ellos realizan sus esfuerzos exitosos sino cuan bien ellos contienen sus riesgos".

Los "Posibilitadores Organizacionales" en el OPM3

La Segunda versión del OPM3 (Organizational Project Management Maturity Model), define una serie de Mejores Prácticas en los procesos de Gestión Organizacional de Proyectos (Organizational Project Management), que están soportadas por unos "Posibilitadores", o "Enablers".

El tener dichos posibilitadores, ayuda a que la organización implemente con mayor facilidad sus mejores prácticas en la gestión de proyectos, programas y portafolios, permitiendo así lograr los objetivos estratégicos planteados. También ayudan a la sostenibilidad de las mejoras planteadas.

Los siguientes son algunos "posibilitadores".. Piense si en su organización usted puede observar la existencia de alguno o varios de estos elementos:

• 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

La examinación (assesment) del nivel de madurez requiere de la participación de consultores con conocimientos en las bases de OPM3, que permitan ayudarlo a definir la mejor ruta para madurar y así mejorar su capacidad de lograr sus estrategias.

Liderazgo

Una competencia crítica para el éxito del Gerente de Proyectos es el Liderazgo.

Desde hace varios años David Fischman viene difundiendo e impulsando temas referentes a liderazgo.

En su página web podrán encontrar artículos, podcasts, entrevistas, y un calendario de sus próximas conferencias.

Congreso PMI Lima Peru 2009

El próximo Jueves 29 y Viernes 30 de Octubre se llevará a cabo el Congreso Internacional de Gerencia de Proyectos del Capítulo Lima Perú del PMI, como parte del V Tour Cono Sur 2009. Haz click aquí para inscribirte.

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	Conferencia 1a: Brian Weiss, MBA, USA. Tema: "PMI Strategic Events and Certification Strategies".			Conferencia 1b Edgar Ricardo, Quiroz Villón, Mg, MSc, Perú. Tema: "Gestión de Riesgos en Proyectos de Construcción".		Conferencia 1c William Alonso Gutiérrez Sandí, MBA, MAP, PhD, Costa Rica. Tema: "Gestión de Proyectos de "I+D+I"".
11:10	11:40	Cofee Break			Cofee Break		Cofee Break
11:40	12:30	Conferencia 2a Victor Anyosa, PMP, Perú. Tema: "Linkeando la Estrategia de Negocios con el Portafolio de Proyectos de las Organizaciones".			Conferencia 2b Jorge Seura, PMP, Chile. Tema: "Lecciones Aprendidas en la Implementación de la Branch Antofagasta del PMI Santiago Chile Chapter".		Conferencia 2c Tito Suárez-Bråthen, MSc, PMP, USA. Tema: "Aspectos culturales y de comunicación en equipos de trabajo virtuales".
12:30	13:20	Conferencia 3a Linda Salac, MA, MIT, USA. Tema: "Construyendo puentes sin fronteras con proyectos".			Conferencia 3b Gustavo Reynoso Begazo, MBA, PMP, Perú. Tema: "Estrategia y Portafolio de Proyectos Mineros".		Conferencia 3c Fernando Contreras Velásquez, PMP, PMI-SP y PMI-RMP Perú. Perú. Tema: "Gestión de Problemas en el Cronograma según el PMBOK 2008".
13:20	15:00	Almuerzo			Almuerzo		Almuerzo
15:00	15:50	Conferencia 4a Mario Salmona, PMP, SCPM, Chile. Luis Rosales Zepeda Tema: "Desarrollo Sostenible en la Dirección de Proyectos, aplicado en Cia. Minera Xstrata Lomas Bayas – Chile".			Conferencia 4b Ángel Omar Gonzales Vera, PMP, Perú. Tema: "Gestionando pequeños proyectos electromecánicos – un reto constante de la pequeña y mediana empresa".		Conferencia 4c Carlos Acuña Valencia, PMI-SP, PMI-RMP, PMP, Perú. Tema: "La certificación CBAP® (Analista de Negocios Profesional) ¿Complemento o competencia a las certificaciones del PMI?".
15:50	16:40	Conferencia 5a John Patton, MBA, PMP, USA. Tema: "Ciclos de Vida para Dirección de Portafolios y Programas".			Conferencia 5b André Augusto Choma, PMP, Brasil-USA. Tema: "Éxito vs. Fracaso - ¿Cuál es la Diferencia entre los Mejores y los Peores Proyectos?".		Conferencia 5c Carlos E. Rázuri Sánchez, MSc, PMP, Perú. Tema: "Integrando la metodología de Valor Ganado y el Sistema Last Planner para la Gestión exitosa de proyectos".
16:40	17:10	Cofee Break			Cofee Break		Cofee Break
17:10	18:00	Conferencia 6a Rolando Guevara Ruiz, PMP, Costa Rica. Tema: "Las Relaciones Interpersonales: Un Factor Crítico para el Éxito en la Dirección de Proyectos".			Conferencia 6b Felipe Meléndez, MBA, PMP, Perú. Tema: "Frente a las amenazas en los Proyectos de perforación de sus pozos petroleros".		Conferencia 6c Andrew Wood, PMP, Inglaterra. Tema: "Cuando el fracaso se vuelve éxito en un Proyecto".
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	Conferencia 1a Liliana Buchtick, PMP, USA Tema: "Dominio del WBS en proyectos del mundo real".			Conferencia 1b Manuel Alvarez, MAP, Costa Rica. Tema: "Madurez Organizacional en Gestión de Proyectos: Avance, Retroceso o Lección Aprendida".		Conferencia 1c Juan José Cárdenas, PMP, Perú. Tema: "Requerimientos: La asignatura pendiente de los Gerentes de Proyecto".
09:50	10:40	Conferencia 2a José Alfredo Díaz León, MBA, MGTI, Peru. OSINERGMIN Alfonso D. Núñez Fernández, MBA, PMP. Tema: "Implementación de las PMO en organismos gubernamentales".			Conferencia 2b Cecilia Boggi, PMP, Argentina. Tema: "Proyecto de mejora de Desarrollo de Software CMMI – un caso de éxito".		Conferencia 2c Mario Alexandre Carmo Canedo Medeiros, PMP, Brasil. Tema: "Experiencias colectadas a lo largo de la implantación de procedimientos y de la ejecución de proyectos con equipos geográficamente distribuidos".
10:40	11:10	Cofee Break			Cofee Break		Cofee Break
11:10	12:00	Conferencia 3a Darlene Williams, PhD, USA. Tema: "Professional ethics and responsibility".			Conferencia 3b Aldo Mario González Córdova, MBA, PMP, Perú. Tema: "El Mapa de Stakeholders para la Gestión Eficiente de los Interesados en Proyectos de Ingeniería (EPCM) en Organizaciones Funcionales".		Conferencia 3c Jorge Luis Rossini, MBA, Brasil-Argentina. Tema: "Los 7 hábitos de un proyecto eficaz".
12:00	12:50	Conferencia 4a Gloria Quintanilla, PMP, México. Víctor Reyna, PMP PERU Tema: "Gobierno y Gestión de Servicios Tercerizados de Tecnologías de la Información (TI)".			Conferencia 4b Vicente J. Granadino Galindo, MBA, PMP, Perú. Tema: "Aplicación de la Gestión de RRHH en el éxito de un Proyecto Estratégico del Banco de Crédito BCP".		Conferencia 4c Medardo Delgado Paredes, Ingº, Perú. Tema: "Modelo de Procesos de Software para Pequeñas y Medianas Organizaciones de Software - MoProsoft".
12:50	14:30	Almuerzo			Almuerzo		Almuerzo
14:30	15:20	Conferencia 5a Luis Humberto Bravo Salomón, Mg, Perú. Tema: "Aplicación del principio de la Carga Vertical en el Trabajo para el Desarrollo del Equipo del Proyecto".			Conferencia 5b Álvaro Augusto Vallejos Puño, MSc, Perú. Tema: "Descubriendo el concepto de “diversidad” y aplicando una metodología para gestionarla adecuadamente en el marco de un proyecto".		Conferencia 5c Oscar A. Gimenez, MSc, Venezuela. Tema: "Administración del Cambio en los Proyectos".
15:20	16:10	Conferencia 6a Carmen Iriarte Blas, MBA, PMP, Perú. Tema: "Manejo del Riesgo mediante la aplicación de una Prueba de Concepto en un Proyecto de Implementación de Software enlatado".			Conferencia 6b Jose A. Ortiz, MBA, PMP, USA. Tema: "Aplicando un modelo electrónico (e-Procurement) para la obtención de bienes y servicios y alcanzar ventajas necesarias en medio de la globalización".		Conferencia 6c Edwin Monzón Cuya, PMI-SP, PMP, Perú. Tema: "Control de Proyectos Capitales".
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

.

Plan de Gestión de Proyectos - PMBOK(r) Cuarta Edición

Este documento contiene el contenido del plan de gestión de proyectos según la Guía para el PMBOK(r), Cuarta Edición, con algunos comentarios:

Open publication - Free publishing - More pmbok

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

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).

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

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.

Enlaces con la Organización y Gestión de Costos??

La Guía para el PMBOK(r) requiere que el plan de gestión de los costos del proyecto incluya información sobre la relación entre los códigos de la EDT y las cuentas de activización de la organización.
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.