Método Simple para Planear el Trabajo con Interesados

-----------------------------------------------------------------------

Tambien en:

Scribd: https://www.scribd.com/doc/305502078/Metodo-simple-para-Planificar-el-trabajo-con-Interesados

SlideShare: http://es.slideshare.net/contesl/un-mtodo-simple-para-planificar-el-trabajo-con-interesados

Linkedin: https://www.linkedin.com/groups/4274830/4274830-6117699238441873410

Worpress: https://bawarp.wordpress.com/2016/03/21/metodo-simple-para-planificar-el-trabajo-con-interesados/

----------------------------------------------------------------------

Introducción

Cuando empezamos a transitar el camino de "traducir" la necesidad de negocio en acción generando la solución esperada necesitamos identificar las personas, grupos u organizaciones que nos guiarán para analizar sus expectativas y desarrollar la estrategia para trabajar en conjunto. Esta acción es un factor clave para el éxito del trabajo de Análisis de Negocio porque, metafóricamente hablando, el Analista de Negocio es el rol que asegura que todo lo esperado se hace realidad. La actividad es conocida como Administración de los Interesados y se realiza desde el “minuto cero” del ciclo de vida[1] de la solución.

Por definición, un interesado es "persona u organización cuyos intereses pueden verse positiva o negativamente afectados por la solución o el proceso para generar la solución". La palabra clave es "afectada" porque esta situación va a generar actitud positiva o negativa y es por esto que tenemos que empezar tan pronto como sea posible una estrategia de gestión.

Lo que sigue es un método práctico que he utilizado desde hace muchos años con buenos resultados y que comprende dos fases clave (siendo un proceso continuo a lo largo de todo el ciclo de vida de la solución):

• Identificar Interesados: el proceso de identificar las personas, grupos u organizaciones que pueden impactar o ser impactados por una decisión, actividad o resultado de la iniciativa de crear la solución.
• Planificar el Trabajo con Interesados: el proceso de desarrollar estrategias para trabajar con los interesados y lograr la participación efectiva a través de toda la iniciativa, basado en el análisis de sus necesidades y el potencial impacto sobre el proceso de crear la solución.

Es posible entonces que al lector también le dé resultado esté método práctico. Y por supuesto, todo comentario es más que bienvenido.

Identificar Interesados.

Como se expuso anteriormente es el proceso de identificar las personas, grupos u organizaciones que pueden impactar o ser impactados por una decisión, actividad o resultado de la iniciativa de crear la solución. Es muy importante prestar atención que estamos realizando una actividad de Elicitación (espero escribir un artículo sobre esto en breve).

Como guía para minimizar la probabilidad de obviar algún interesado se utiliza como base el concepto sistémico aplicado a la organización y los conceptos de arquitectura empresarial. Utilizando el pensamiento sistémico [Bunge 1979], el analista de negocios es consciente de que el cambio tendrá un impacto en la arquitectura de la empresa.

La Arquitectura Empresarial (EA) es definida por Gartner como "una disciplina para, de manera proactiva y holística, liderar las respuestas de la empresa a fuerzas disruptivas mediante la identificación y el análisis de la ejecución del cambio teniendo en cuenta la visión y los resultados de negocio deseados.  EA se utiliza para dirigir las decisiones que se toman para lograr la evolución de la arquitectura hacia el estado futuro deseado". [Gartner Group 2013]

La Arquitectura Empresarial podría describirse básicamente como consistente en varias arquitecturas altamente independientes, altamente cohesivas, según el modelo a continuación:

Figura 1: Arquitectura empresarial.

• Arquitectura de Negocios (BA): es el puente entre la estrategia y el negocio en funcionamiento. Cada vez que el ambiente interactúa con el negocio es a través de la Arquitectura de Negocios.
• Arquitectura de Aplicación (AA): describe la estructura y comportamiento de las aplicaciones utilizadas en un negocio, y se centra en la forma en que interactúan entre sí y con los usuarios para apoyar componentes de la Arquitectura de Negocios.
• Arquitectura de Tecnología (TA): es la tecnología utilizada para apoyar los componentes de la Arquitectura de Aplicaciones.
• Arquitectura de Seguridad (SA): es un diseño de seguridad coherente, que se ocupa de los requisitos (por ejemplo, la autenticación, autorización, etc.) - y, en particular, los riesgos de un entorno / situación específica, y describe qué controles de seguridad se aplicarán y dónde.
• Arquitectura de la Información (IA): es una combinación de organización,  etiquetado, y  modelos de navegación, y los mecanismos de recuperación, dentro de un espacio de información.

Podemos utilizar la Arquitectura Empresarial como un mapa para descubrir personas, grupos u organizaciones que serán los componentes de nuestra Lista de Interesados o también llamado Registro de Interesados. Y estas personas, grupos u organizaciones pueden ser tanto internas como externas a nuestra organización (para lo externo sirve tener en mente la concepción sistémica ya que la organización es un sistema adaptable y abierto interactuando con el medio ambiente –posiblemente algunos los llamen mercado).

En este punto, el Registro de Interesados puede completarse con la información de identificación, a saber[2] :

• Nombre
• Posición en la Organización
• Localización
• Información de Contacto

Planificar el Trabajo.

Como se expuso anteriormente es el proceso de desarrollar estrategias para trabajar con los interesados y lograr la participación efectiva a través de toda la iniciativa, basado en el análisis de sus necesidades y el potencial impacto sobre el proceso de crear la solución.

En una primera etapa cada interesado se clasifica utilizando una matriz. En el caso de este proceso práctico la matriz utilizada es la matriz de Influencia/Impacto, pero podrán encontrar diferentes combinaciones en la literatura sobre el tema. De nuevo, es crítico entender que esta información se completa a partir de la elicitación realizada con el interesado. Es decir, estamos utilizando lo que cada interesado expresó durante la elicitación.

En la figura 2 puede verse un ejemplo de Matriz de Influencia/Impacto. En el contexto del presente trabajo, Influencia se define como la capacidad de un interesado de modificar las decisiones de cualquier otro involucrado en el proceso de generar la solución mientras que Impacto es el grado en el que la solución lo afecta.

No importa el tipo de matriz que se utilice (otras son Poder/Interés, Poder/Influencia, Influencia/Interés) todas coinciden en la determinación de la estrategia a seguir una vez clasificados, a saber:

• Keep Satisfied (KS): prestar atención a sus requerimientos pero no aburrirlos con la comunicación constante.
• Manage Closely (MC): son los interesados clave que debemos mantener involucrados a lo largo de todo el proceso de creación de la solución.
• Monitor (MO): tenerlos siempre en cuenta porque pueden cambiar de clasificación a lo largo del proceso de creación de la solución, generalmente se destina tiempo a detectar estos cambios y mantenerlos informados.
• Keep Informed (KI): se les envía información, se escuchan y registran sus necesidades, se trabaja sobre sus ansiedades.

Figura 2: Un ejemplo de matriz de Influencia/Impacto

Luego de la clasificación, estamos listos para completar la etapa de definición de estrategias y completar la información faltante en el Registro de Interesados, a saber:

• Nivel de Influencia (Alto, Medio, Bajo).
• Nivel de Impacto (Alto, Medio, Bajo).
• Estrategia según Análisis (KS, MC, MO, KI).
• Estrategia a Seguir (KS, MC, MO, KI). Por caso que debamos moverlo de cuadrante a efectos de lograr los objetivos de la solución.
• Elevator Speech. Este es un concepto muy interesante que cuando se pone en práctica proporciona enormes beneficios. Se trata de registrar allí la frase que le diríamos a un interesado para cambiar su estado teniendo en cuenta que el tiempo disponible para lograrlo es la duración de un viaje en ascensor entre dos pisos contiguos.

Figura 3: Un ejemplo de Registro de Interesados

Conclusión

Mucho se podría seguir escribiendo respecto a todo lo relacionado con interesados. Pero este documento persigue describir en forma simple un método práctico que ha dado resultado durante años para comenzar la desafiante tarea de generar la solución “que todos esperan” y lograr que “los sueños de los interesados se hagan realidad”.

Referencias

 [Bunge 1.979] Mario Bunge. 1979. Un mundo de sistemas. Dordrecht; Boston, Reidel.

[Gartner Group 2013] Gartner Group. Gartner Glosario de TI. Http://www.gartner.com/it-glossary/enterprise-architecture-ea/

[Bertalanffy 1968] Ludwig von Bertalanffy. 1968. teoría del sistema general: Fundamentos, Desarrollo de Aplicaciones. Nueva York: George Braziller, edición revisada 1976: ISBN 0-8076-0453-4

[1] Ciclo de vida puede definirse como el tiempo que transcurre desde la idea hasta la disposición o modificación de la solución.

[2] Recordar que la definición de cualquiera de las salidas del trabajo de Análisis de Negocio se realiza durante el proceso de Planificación del Análisis de Negocio. El detalle que se muestra es un ejemplo práctico fruto de la utilización práctica.

New group to discuss business analysis and agile IN SPANISH.

He generado un grupo en linkeding para discutir temas de análisis de negocio y agile en español y asi poder aprender entre todos un poco mas cada dia.

https://www.linkedin.com/grp/home?gid=4274830

Sección 6:  Evaluación de la Solución (Solution Evaluation)

Introducción.

La intención de esta serie de artículos es divulgar la Guía Práctica del Análisis de Negocio (“La Guía”, en los párrafos siguientes) recientemente publicada por el PMI®. Esta organización reconoce el crecimiento de la profesión del Análisis de Negocio y su importancia como factor crítico de éxito de cada proyecto o programa que las organizaciones emprenden para solucionar sus problemas de negocio satisfaciendo sus necesidades de transformación. La Guía incluye también puntos aclaratorios respecto de cómo el Analista de Negocio (“BA” en lo que sigue) y Administrador de Proyectos (“PM” en lo que sigue) colaboran para lograr los objetivos del emprendimiento.

6.1. Resumen.

Según La Guía desde la evaluación consiste en las actividades para validar la solución completa o un segmento de la solución que está por implementarse o ya ha sido implementada, para determinar si la solución cumple las necesidades del negocio expresadas por los interesados incluyendo la entrega de valor para el cliente. Algunas actividades resultan en la evaluación cuantitativa o cualitativa. Todas las técnicas expuestas en esta sesión pueden utilizarse dentro de modelos de ciclo de vida de proyectos predictivos, iterativos o adaptativos. Algunas de estas técnicas pueden ser utilizadas durante las actividades de análisis de requerimientos o evaluación de necesidades. También puede decirse que hay algún solapamiento entre las técnicas de evaluación y las técnicas de trazabilidad.

6.2. Propósito de la Evaluación.

En el apartado 6.2 La Guía establece que las actividades de Evaluación de la Solución permiten conocer si una solución está cumpliendo con el resultado de negocio esperado. La Evaluación provee de entradas a las decisiones de negocio y técnicas sobre el go/no-go al implementar la solución completa o un segmento de la misma. También puede utilizarse para decidir si una solución en uso merece ser modificada o no.

6.3. Mindset.

Diferentes ciclos de vida colocan la evaluación en distintos puntos del ciclo. La Guía recomienda la utilización de la evaluación en modo continuo para identificar las áreas de la solución que requieren un nivel de testeo mayor. La articulación de la evaluación en forma temprana es un medio excelente para confirmar los requerimientos funcionales y no funcionales.

En el apartado 6.3.2 La Guía establece que la mejor herramienta para evaluar la solución desde el punto de vista de los requerimientos y su asociación a objetivos y metas de negocio es la matriz de trazabilidad.

Collaboration Point: el BA, el PM y los testets deberían trabajar juntos bien temprano en el proceso de generación de la solución para crear las actividades necesarias relativas al análisis, prueba (testing) y evaluación. Los testers pueden ayudar en crear las actividades en forma completa y consistente mientras que el BA puede ayudar en asegurar en cubrir todas las áreas de la solución que tienen la mayor prioridad de negocio.

En el apartado 6.3.3 La Guía hace mención a que evaluar la solución es más complejo que validar o determinar si los requerimientos individuales fueron alcanzados. Durante la evaluación hay que asegurar que la solución alcanza los objetivos propuestos mientras que durante la validación el foco debería ser que los requerimientos se han implementado de acuerdo a lo acordado con los interesados. Cobra gran importancia asegurar en este punto que los requerimientos no funcionales que afectan la evaluación de la solución se cumplen según lo acordado.

En el apartado 6.3.4 La Guía hace mención explícita a no perder el foco en evaluar aquellas partes de la solución que manipulan datos y generan información.

6.4. Plan para Evaluación de la Solución.

Según La Guía emprender actividades de evaluación no es una tarea trivial. Toma tiempo y esfuerzo identificar y confirmar el criterio de evaluación, implementar todo lo necesario para tomar mediciones y reportar y analizar esas mediciones.

Algunos factores a considerar cuando se planean las actividades de evaluación son:

• Definir todos los reportes y publicaciones con foco en las metas, objetivos y riesgos organizacionales que la evaluación tiene que cubrir
• Identificar quién cubre los costos por el tiempo y el esfuerzo de las actividades de evaluación
• Determinar el criterio de evaluación de la solución completa
• Determinar el impacto en costo y tiempo del método de evaluación y su relación con el beneficio

6.5. Determinar QUÉ Evaluar.

Hay que recordar que se evalúa una solución a punto de implementarse o una solución que está siendo utilizada para determinar algún cambio. La Guía muestra algunos puntos a tener en consideración tales como:

• 6.5.1. Considerar las metas y objetivos de negocio, que dieron origen a la solución
• 6.5.2. Considerar indicadores de rendimiento clave (KPI), que pueden dar origen a los objetivos de la solución y del proyecto
• 6.5.3. Considerar métricas de evaluación y de criterio de aceptación adicionales, tales como:
  • Métricas del proyecto, considerando que el proyecto es parte de la solución
  • Métricas del cliente, tales como satisfacción
  • Métricas de ventas y marketing
  • Métricas operacionales, tales como la tarjeta balanceada (BSC)

Luego de determinar estos puntos hay que decidir si la organización puede continuar con la evaluación, sobre todo desde el punto de vista de los costos y su beneficio.

6.6. Cuándo y Cómo Validar los Resultados de la Solución.

En este punto La Guía vuelve a mencionar el impacto que tiene la utilización de uno u otro tipo de ciclo de vida (básicamente predictivo o adaptativo).

En las secciones 6.6.1 a 6.6.7 La Guía enumera una cantidad de técnicas de evaluación mayormente usadas tales como Focus Group, Pruebas de Usuario,  Pruebas Day-in-the-Life (DITL), Pruebas de Integración, Funcionalidad Actual vs Esperada de requerimientos funcionales y no funcionales, Calculo de Beneficios.

6.7. Evaluar el Criterio de Aceptación y Solucionar Defectos.

En este punto, los resultados obtenidos deben compararse con los resultados esperados (6.7.1). Con foco en los rangos de tolerancia acordados (6.7.2) se registran defectos en un log (6.7.3) de ser necesario para el posterior seguimiento de las soluciones o propuestas de mejora.

6.8. Facilitar la Decisión de Go/No-Go.

Si la evaluación se realizó sobre una solución o parte de una solución que será implementada los interesados, de acuerdo a su nivel de identificación en la matriz RACI (desarrollada en el proceso de Planificación – Sección 3), deberán decidir si continuar o no. Los resultados de la evaluación deberían ser presentados de forma tal que puedan ser fácilmente entendidos por todos los interesados que actuarán en el proceso de decisión. Es recomendable, según La Guía, que las decisiones se tomen durante una reunión presencial.

6.9. Obtener la Firma (Singoff) de la Solución.

La RACI desarrollada en la Sección 3 – Planeamiento del Análisis de Negocio designa quién es “accountable” para firmar el acuerdo sobre la solución. La formalidad dependerá del tipo de proyecto, el ciclo de vida y regulaciones corporativas. En los casos de organizaciones que utilizan un proceso formal este debería registrarse en un documento.

Collaboration Point: el PM y el BA trabajan junto a los interesados de auditoría para determinar la práctica de firma (signoff) que la organización requiere.

6.10. Evaluar la Prestación de la Solución.

Uno de los puntos más críticos en el trabajo del BA es evaluar si la solución generada y/o implementada está obteniendo los beneficios de negocio que le dieron origen. Es bueno recordar que el trabajo del BA se realiza tanto para generar una nueva solución como para ayudar a la decisión de cambiar o modificar una solución existente. Para poder identificar el cambio o modificación en una solución es crítico haber definido métricas sobre la prestación de la solución.

Las actividades de Evaluación de la Prestación de la Solución que propone La Guía son:

• 6.10.11. Determinar las Métricas. El PM y el BA deben trabajar junto con los interesados para identificar y priorizar los aspectos de prestación que deben ser monitoreados.
• 6.10.12. Obtener las Métricas/Medidas de Prestación.
• 6.10.13. Analizar los Resultados.
• 6.10.14. Evaluar las Limitaciones de la Solución y de la Organización.
• 6.10.15. Recomendar el Enfoque para Mejorar la Prestación de la Solución.

 6.11. Remplazar o Eliminar la Solución.

Luego de la Evaluación de la Solución, dependiendo de los resultados, quizá la decisión de remplazar o eliminar la solución debe tomarse. Según La Guía, dependiendo del resultado de un análisis de costo y beneficio, los caminos a seguir pueden ser:

• Cutover masivo. Remplazar o eliminar toda la solución en una sola vez.
• Cutover segmentado. De acuerdo a un criterio eliminar o remplazar partes mientras otras existen incluso con una nueva solución implementada.
• Remplazo time-boxing. Definir el momento de remplazo o eliminación acuerdo a los tiempos de negocio.
• Coexistencia permanente. La solución persiste independientemente que una nueva se implemente.

Sin importar la estrategia definida es crítico que el BA y el PM trabajen juntos para definir las actividades relacionadas con la comunicación y el involucramiento de los interesados claves.

Conclusión.

Esta sección de La Guía está en línea con el Área de Conocimiento 7-Solution Assessment and Validation de la Guía BABOK® del IIBA® versión 2. El lector encontrará, en caso de comparar ambas guías, que esta última es mucho más consistente en puntos tales como las técnicas y métodos para encontrar las necesidades del negocio. Vale aclarar que el PMI® ha señalado que esta es la primera versión de La Guía y que sufrirá evoluciones.

BA by PMI® – Entendiendo la Guía Práctica del Análisis de Negocio

Sección 5: Trazabilidad y Monitoreo (Trazability and Monitoring)

Introducción.

La intención de esta serie de artículos es divulgar la Guía Práctica del Análisis de Negocio (“La Guía”, en los párrafos siguientes) recientemente publicada por el PMI®. Esta organización reconoce el crecimiento de la profesión del Análisis de Negocio y su importancia como factor crítico de éxito de cada proyecto o programa que las organizaciones emprenden para solucionar sus problemas de negocio satisfaciendo sus necesidades de transformación. La Guía incluye también puntos aclaratorios respecto de cómo el Analista de Negocio (“BA” en lo que sigue) y Administrador de Proyectos (“PM” en lo que sigue) colaboran para lograr los objetivos del emprendimiento.

5.1. Resumen.

Según La Guía desde la perspectiva de la Guía PMBOK® Quinta Edición la trazabilidad y el monitoreo se componen de las actividades que aseguran que los requerimientos son aprobados y administrados a través del ciclo de vida del proyecto. La matriz de trazabilidad se genera y utiliza como herramienta para monitorear y control el alcance del producto. Los requerimientos aprobados serán administrados en una línea de base de requerimientos y de esta forma todo nuevo requerimientos se documentará, se agregará a la matriz de trazabilidad, se evaluará el impacto que pueda ocasionar al producto y al proyecto y se presentarán a los interesados para su aprobación utilizando el método de comunicación definido y aprobado en el plan de análisis de negocio.

5.2. Trazabilidad.

La Trazabilidad provee la posibilidad de realizar el seguimiento de los requerimientos del producto desde el origen hasta los entregables. Generalmente recibe el calificativo de “bidireccional” o también “hacia adelante (forward) y hacia atrás (backward)”. En este documento el concepto de Trazabilidad está totalmente alineado a lo expresado en la Guía PMBOK® Quinta Edición.

Collaboration Point: las decisiones respecto del proceso de Trazabilidad se realizan durante la etapa de Planificación del Análisis de Negocio (Sección 3 de esta guía). El BA debería trabajar con el PM para determinar el grado de trazabilidad apropiado balanceando la utilización de los recursos destinados con el riesgo de no tener la trazabilidad adecuada. Para esto es crítico entender que el PM es responsable por administrar el alcance del proyecto mientras que el BA es el responsable por administrar el alcance del producto. El proceso de trazabilidad de requerimientos es un claro ejemplo de administración del alcance del producto.

En el apartado 5.2.2 La Guía presenta algunos beneficios de mantener la trazabilidad de los requerimientos tales como asegurar que cada requerimientos agrega valor al negocio, ayudar a alcanzar las expectativas de los interesados, ayudar a mantener el alcance del producto y del proyecto.

5.2.3. La Matriz de Trazabilidad.

La Guía propone la utilización de esta herramienta para administrar la trazabilidad de requerimientos. La define como una grilla que permite enlazar los requerimientos del producto con los entregables que los satisfacen. Entre otros valores agregados es el medio que permite enlazar cada requerimiento a los objetivos del proyecto y del negocio para demostrar el valor agregado que el requerimiento provee.

Por cada requerimiento la matriz muestra una breve descripción e informaciones adicionales que se conocen como “atributos”. Los atributos ayudan a definir la información clave sobre los requerimientos y usualmente cada atributo se corresponde con una columna de la matriz.

El tipo y cantidad de atributos debería ser al apropiado para las necesidades de la organización y el ciclo de vida de proyecto. Si la Matriz de Trazabilidad no existe como activo de la organización deberá ser creada como parte del proceso de Planeamiento del Análisis de Negocio. Para más información sobre los atributos de los requerimientos hay que referirse a la Guía PMBOK® Quinta Edición.

La Matriz de Trazabilidad puede utilizarse en forma jerárquica comenzando de los requerimientos de alto nivel y llegando a los requerimientos detallados.

Collaboration Point: algunas organizaciones desarrollan un template de la matriz como punto de partida. Durante la actividad de Planeamiento del Análisis de Negocio el BA colabora con el PM y los interesados para determinar los componentes del template.

5.3. Relaciones y Dependencias.

Según La Guía la Matriz de Trazabilidad es la herramienta soporte para determinar el análisis de dependencias y los análisis de impacto. Algunas de las relaciones de dependencia son:

• Subconjunto. Un requerimiento puede ser subconjunto de otros requerimientos.
• Implementación. Un requerimiento no puede implementarse si otro/s no se implementa.
• Valor o Beneficio. El beneficio o valor de un requerimiento no puede alcanzarse si no se implementa primero otro/s requerimientos.

5.4. Aprobación de Requerimientos.

La Guía reconoce que dependiendo de la cultura de la organización la aprobación de requerimientos puede ser más formal o menos formal. Más allá de eso pone énfasis en que el proceso de aprobación debe estar determinado, documentado y aprobado antes de realizar la actividad de Planificación del Análisis de Negocio (Sección 3 de La Guía).

Según La Guía, el proceso de aprobación debería incluir:

• 5.4.1. El Sistema de Autorización del Trabajo (Work Authorization System).
• 5.4.2. Niveles de Aprobación

5.5. Línea de Base de Requerimientos Aprobados.

5.5.1. ¿Qué es una Línea de Base de Requerimientos?

Es el límite que contiene todos los requerimientos aprobados del proyecto, una fase del proyecto, iteración, incremento, reléase o cualquier otra parte del proyecto. La Línea de Base provee un mecanismo para comparar y reconocer cualquier cambio que ocurre y evaluar el impacto del cambio a través de los mecanismos del control de cambios.

5.5.2. Relaciones entre la Línea de Base de Requerimientos, el Alcance del Producto y el Alcance del Proyecto.

El Alcance del Proyecto es el trabajo realizado para entregar el producto, servicio o resultado. El Alcance del Producto está compuesto de las características y funciones que definen el producto, servicio o resultado. Los requerimientos describen esas características y funciones y hay una relación directa con el alcance del proyecto porque cuantos más requerimientos se incluyan mayor será el alcance del proyecto.

En el apartado 5.5.3 La Guía hace mención a la importancia de mantener el “product backlog” en los ambientes con ciclo de vida adaptativo.

5.6. Monitoreo de Requerimientos utilizando una Matriz de Trazabilidad.

La herramienta propuesta para administrar los requerimientos es la Matriz de Trazabilidad. En el apartado 5.6.1 se enumeran una serie de beneficios que se obtienen al utilizarla siendo el mayor de ellos la prevención del “Scope Creep”.

5.7. El Ciclo de Vida de Requerimientos.

El estado del requerimiento es uno de los atributos que serán incluídos en la Matriz de Trazabilidad.  El estado caracteriza dónde se encuentra el requerimiento dentro del ciclo de vida de requerimientos. La Guía hace expresa mención a que el Ciclo de Vida de Requerimientos no debe ser confundido con el Ciclo de Vida del Proyecto.  El Ciclo de Vida de Requerimientos se define durante la Planificación del Análisis de Negocio (Sección 3 de La Guía).

5.8. Administrando los Cambios a los Requerimientos.

El proceso de Administración de Cambios a Requerimientos se define durante el proceso de Planificación del Análisis de Negocio (Sección 3 de La Guía). Pero este debe ser parte integrante (o el mismo) del Proceso de Administración de Cambios del Proyecto. El BA ayudará en este caso a generar la información necesaria para administrar el cambio dentro del Proceso de Administración de Cambios del Proyecto.

En el apartado 5.8.1 se hace expresa mención respecto a que el rol del BA durante el proceso de control de cambios es mantener la integridad respecto de los requerimientos y sus entregables.

Collaboration Point: El PM y el BA trabajarán juntos para evaluar los impactos del cambio propuesto tanto en el alcance del proyecto como en el alcance del producto.

En el apartado 5.8.2 La Guía enumera una serie de técnicas y herramientas de control de cambios. Dentro de ésta se listan:

• 5.8.2.1. Sistema de Administración de la Configuración (CMS).
• 5.8.2.2. Sistema de Control de Versiones (VCS).

La Guía hace mención a la importancia del Análisis de Impacto (Impact Analysis) en el apartado 5.8.3. El Análisis de Impacto debe realizarse tiendo en cuenta de qué forma el cambio propuesto afecta otros requerimientos, el producto, el proyecto y el programa. En los apartados 5.8.3.1 a 5.8.3.5 La Guía hace una descripción general de un proceso formal para el análisis de impacto incluyendo:

• 5.8.3.5.1. Revisar el impacto a la Línea de Base de Requerimientos, que debería ser realizado por el BA.
• 5.8.3.5.2. Revisar el impacto en cuanto a conflicto con otros requerimientos, que debería ser realizado por el BA.
• 5.8.3.5.2. Revisar el impacto en el trabajo de Análisis de Negocio, que debería ser realizado por el BA.
• 5.8.3.5.3. Revisar el impacto en el trabajo de Administración de Proyecto, que debería ser realizado por el PM trabajando en conjunto con el BA.
• 5.8.3.5.4. Recomendar un curso de acción, que debería ser realizado por el BA luego de compilar toda la información de impacto para ser presentado al grupo que decide sobre el cambio.

5.8.4. Control de los Cambios relacionados con Defectos.

Debido a que un defecto es un desvío respecto de los requerimientos el BA se involucra en la reparación de defectos monitoreando la misma. La información de detalle sobre este proceso se encuentra en la Sección 6 – Evaluación de la Solución de La Guía.

Conclusión.

Esta sección de La Guía está en línea con el Área de Conocimiento 4-Requirements Management and Communications de la Guía BABOK® del IIBA®. El lector encontrará, en caso de comparar ambas guías, que esta última es mucho más consistente en puntos tales como las técnicas y métodos para encontrar las necesidades del negocio. Vale aclarar que el PMI® ha señalado que esta es la primera versión de La Guía y que sufrirá evoluciones.

La Guia Practica del Analisis de Negocio del PMI. Traduccion completa al español.

SlideShare: http://www.slideshare.net/contesl/in-spanish-pmis-pgba

WordPress: https://bawarp.wordpress.com/2016/02/05/en-espanol-guia-practica-del-analisis-de-negocio-pmi/

G+: https://plus.google.com/u/0/b/117290412180005147641/+Bawarp/posts/p/pub?_ga=1.163576373.827487500.1454695937