Evaluación del impacto por deficiencia en los requerimientos

Este articulo se basa en un reporte creado por la consultoría AIG, sobre el impacto que tienen la deficiencia en la toma de requerimientos, el reporte presenta hallazgos que fuero recopilados de las encuestas realizadas a mas de 100 grandes compañias norte-americanas en las cuales sus proyectos de desarrollos de sistemas de software son en promedio de un tamaño aproximandamente de $3 millones USD, proyectos que tienen cambios significativos para las compañias considerandose estrategicos.

De los hallazgos mas relevantes que se encontraron en este estudio se tiene:

• Hay un 60% de tiempo y costo que se agrega a los proyectos por las deficiencias en los requerimientos
• Menos de la tercera parte de las compañias estan bien equipadas para realizar una toma de requerimientos y su probabilidad de éxito es mayor en relación a las que no cuentan con este equipamientos
• La suboptimización de la toma de requerimientos cosnume aproximadamente el 41% del presupuesto de los proyectos estrategicos de la compañía

El estudio muestra básicamente dos escenarios, donde uno de ellos pertenece a un grupo de empresas que constantemente realizan más 50%  entregas de proyectos exitosos (en tiempo y costo).

El segundo escenario, son de las compañias que generalmente su probabilidad de falla supera el 50%, en los cuales sus entregables estan por encima del costo y tiempo presupuestado, además entregando funcionalidad por debajo de lo que inicialmente se especifico. Estas compañias no son buenas en la toma de requerimientos.

¿Cuál es la relación entre el Analista de Negocio (BA) y el éxito de los proyectos estratégicos?

Es generalmente implícito que la mayoría de los proyectos estratégicos de un negocio, especialmente aquellos que tienen una visión significativa de cambio operacional,  se retrasen sus entregas o que el presupuesto asignado inicialmente quede muy corto y frecuentemente se entrega con menor funcionalidad con la que se visiono.  Por otro lado hay otros proyectos que son entregados en tiempo y costo y además con las funcionalidades inicialmente indicadas.

¿Qué es lo que distingue el  “Abrumador éxito” de todos aquellos que típicamente fracasan?,  ¿cuál es el Rol que  BA realiza en la determinación del éxito del proyecto? y finalmente ¿cuál es el costo de que los requerimientos sean deficientes o poniendo de manera contraría cuál es el beneficio de tener excelentes requerimientos?

Cada Project Manager tiene su propio nivel de convicción sobre el rol del BA y el impacto que tienen en los proyectos. El dato muestra que las viejas creencias acerca de los requerimientos son incorrectas y conllevan a las compañías a tener una probabilidad de 68% de fracaso de los proyectos, aún antes de que estos sean empezados

“El 68% de las compañías simplemente no utilizan los recursos con las competencias necesarias para la realización del análisis de negocio/sistema, esto pone al descubierto que las mimas compañías son responsables de la probabilidad del fracaso del proyecto y a su vez, gastan +50%   (en costo y tiempo) en la solución que una compañía que tiene mejores recursos en el ámbito de las prácticas de BA”.

En los niveles ejecutivos hay una constante lucha por optimizar recursos y producir los resultados necesarios para lograr los cambios en la organización, la investigación muestra que los ejecutivos buscan las mejoras de procesos y abatir el problema de los pobres requerimientos de manera ineficiente. El resultado indica que el promedio de las organizaciones  consumen más del 41.5% de los proyectos nuevos en una deficiente especificación de requerimientos. Para estos ejecutivos la pregunta es: ¿cuál es el impacto generalizado de un análisis pobre sobre la eficiencia de los entregables?, ¿Cómo organizar para minimizar los gastos?, ¿Cuáles son las optimizaciones que hay que realizar en corto y largo plazo en las iniciativas para obtener mejor eficiencia en los entregables?

Para responder estas respuestas IAG lanzo una encuesta a 100 empresas en las cuales se ha realizado proyectos recientes con costos superiores a los 250,000 USD, dentro de esta encuesta se descubre una relación estrecha entre las habilidades de los BA  como factor generalizado de éxito en los proyectos.

La investigación esta soportada en cuantificables conceptos que se encuentran arraigados en varias  culturas corporativas. Por ejemplo, la mayoría de los managers intuitivamente entienden lo complicado que es recuperarse en un proyecto, si el proyecto cuenta con una deficiente toma de requerimientos (negocio y/o de sistema), sin embargo fracasan en poder obtener buenos requerimientos teniendo impactos negativos en el 66% de los proyectos analizados

Además el 20% de las compañías encuestadas han realizado algún tipo de inversión para lograr excelentes requerimientos de negocio y de software sobre una base que sea repetible y eficiente. Este dato sugiere que mientras que la persona intuitivamente reconoce la necesidad de buenos requerimientos, no asimilan el impacto de los requerimientos deficientes. Es también verdad que los recursos que realizan el tema de requerimientos son vistos como simples documentadores sin tener habilidad de analizar y elaborar modelos que permitan crear buenos requerimientos. Los hallazgos de la encuesta claramente indican que solo aquellas compañías que están comprometidas con la excelencia de los requerimientos de negocio y de sistemas a través de mejoras en sus recursos, procesos y la calidad de su documentación/información mejoran a su vez la predictibilidad de éxito en sus proyectos serán de 70% mayor que de las empresas promedios

                 

• Las compañías que mejoran más de la tercera parte de sus requerimientos del proyecto, tienen una probabilidad mayor al 70% de éxito
• Más de la mitad de sus proyectos son entregados en tiempos y presupuestos con las funcionalidades inicialmente indicadas

(Continuara ....)

Beneficios del Análisis de Negocio

Beneficios del Análisis de Negocio

Comenzare por enmarcar los los principales problemas que tenemos día a día, durante el desarrollo de un proyecto y que en un gran porcentaje, está asociado a la ausencia de las mejores prácticas de Análisis de Negocio, en el siguiente análisis de causa raíz podemos ver las principales causas de falla en los proyectos.

                      

 ¿Cuantas veces hemos sido cómplices de una estimación inadecuada, en donde generalmente se comprometen fechas o entregables, aun no teniendo claro el alcance proyecto?, Está es una de las primeras malas practicas que se tienen en el desarrollo de software y que a menudo se traduce en las largas horas laborales (re-trabajo y esfuerzo mal orientado), absorbiendo los riegos del mismo. Cuando dicho problema pudo haber sido mitigado en gran medida, si tan solo se hubiera hecho un análisis mucho más certero a las necesidades reales del negocio.

En la siguiente imagen del cono de Incertidumbre podemos observar que tanto riesgo se tiene el comprometer el proyecto si este no cuenta con los requerimientos de negocio detectados y aprobados.

"Las compañías de software inapropiadamente sabotean sus propios proyectos al comprometerlos al inicio del cono de la incertidumbre.  Si una organización se compromete en la etapa de concepto inicial o durante la definición del producto el factor de error está estimado entre 2x y 4x. El comprometerlo al principio del cono, hacen que el proyecto tenga una predictibilidad indeterminada, incrementando el riesgo de ineficiencia del proyecto, el deterioro de la administración y el éxito del proyecto. 

Por lo que se recomienda que el compromiso no se realice en dichas etapas, donde la amplitud del cono hace que las organizaciones sean ineficientes y absorban los riesgos de ello. Un buen punto para realizar compromisos puede ser, donde la incertidumbre del proyecto esté cerca del 30% (1.3x), en dicho punto se tiene un mejor control y monitoreo de los entregables y avances del proyecto, mejora sustancialmente la eficiencia de los equipos involucrados en el desarrollo"

• La probre definición de los requerimientos entre el negocio y el área de TI trae como consecuencia un 66% de probabilidad de fracaso
• Las compañías que tiene un proceso débil para la toma de requerimientos tiene tres veces mas proyectos fallidos que exitosos
• La compañías pagan un bono extra de alrededor del 60% en tiempo y presupuesto cuando sus proyectos no cuentan con prácticas de requerimientos.
• La gran mayoría de proyectos no utilizan recursos con suficientes habilidades de análisis de negocio para el desarrollo de los proyectos, trasladando el costo a fases posteriores del análisis, donde el costo se multiplica hasta por 10x para la corrección de fallas.
• Si las personas y procesos para realizar análisis de requerimientos están solamente en el promedio, más que en la excelencia, esta deficiencia de excelencia puede consumir aproximadamente el 41% del pre supuesto asignado del proyecto.
• Standish group ha reportado que los proyecto a gran escala tipicamente se pasan al rededor de 189% en su presupuesto y 222% en el tiempo de entrega, donde los principales factores se debe a las prácticas empleadas para la toma de requerimientos

"It’s a myth that the average analyst can be assigned any project. The evidence here: an average analyst will fail to achieve process reengineering objectives over 60% of the time. Average analysts do not deal well with process change objectives. Their requirements discovery process appears to be fundamentally different than that used by elite analysts. Excellence comes through a rethinking of how requirements are  done."

fuente Project Failure - Dan Galorath, Business Analysis Benchmark

Una combinación entre la mejora de las practicas de Análisis de Negocio y la mejora en los procesos de negocio (CMMi, ISO 9000) han probado, que dan enormes diferencias en la productividad del desarrollo de sistemas dando como resultado los siguientes numeros:

• 67% de reducción en el costo de re-trabajo

• del 30% al 40% de reducción en los tiempos de desarrollo

• 90% reducción en defectos

• 350% incremento de la productividad de los equipos de trabajo

funte  Getting Business Requeriments Right

Un estudio del SEI (Software Engineering Institute) encontró que el factor mas importante para mejorar el desarrollo de sistemas, es como la compañía aplica las disciplinas de Recopilación y Administración de los requerimientos.

Por o anterior y para alcanzar los beneficios, debemos de centrar los esfuerzos en el alcance del proyecto (Visión), involucrar los stakeholders correspondientes y organizar y clasificar los requerimientos con el fin de evitar las ambigüedades y las deficiencias de comunicación de las necesidades de negocio.

Los siguientes factores son vital para el éxito del proyecto

• Tener una metodología disciplinada y repetible para controlar las sesiones de recopilación de requerimientos
• Tener a los Stakeholder correctos e involucrarlos solo en las funcionalidades en los que participen (ser eficientes con los tiempos)
• Utilizar un estrategia modular que permita establecer las responsabilidades y colaboraciones de cada servicio de negocio a implementar
• Contar con herramientas para documentar los requerimientos de manera rápida y validar con los stakeholders.
• Establecer un proceso de autorización (sign-off) en el cual se acuerden los requerimientos funcionales y no funcionales de las líneas bases que serán implementadas

BA como consultor

El BA frecuentemente necesita actuar como consultor. Ser consultor significa, proveer consejos de valor hacia las necesidades o áreas de oportunidad del cliente, de tal forma que cree confianza entre los diferentes “StakeHolders”.

Es importante que durante la consultoría se muestre honestidad, franqueza, apertura, la energía de trabajo y el enfoque dedicado, combinándolo con el conocimiento y experiencia, además de saber apoyarse de los equipos de trabajo para lograr crear un consejo o propuesta que sea factible y de valor tanto para el cliente como para los equipos de trabajo.

Entre las habilidades de consultoría está la de saber escuchar. Algunos rasgos de un buen interlocutor incluye; evitar interrupciones, eliminar distracciones, tiende a preguntar al finalizar la idea de quien está hablando, solo en caso de no tener claro el mensaje, confirma el mensaje que ha recibido (parafrasea la idea), muestra un profundo interés en el tema, busca a través de las pregunta mejorar el entendimiento del mensaje. Una Competencia del BA respecto a la habilidad de escuchar es que saber controlar sus emociones evitando concluir con soluciones durante la entrevista, en lugar de ello deberá de orientar las actividades para posteriormente analizarlas y verificarlas con los equipos de trabajo, con el fin de lograr de manera conjunta la propuesta o la solución que le de valor al cliente

El BA tiene poca autoridad o control sobre los “Stakeholder” del proyecto, sin embargo a través de las propuestas bien argumentadas, podrá persuadirlos con la finalidad de lograr un mejor entendimiento y dimensionamiento del proyecto y evaluar las decisiones iníciales en función de asegurar el éxito del proyecto.

El BA deberá de tener una alta competencia para las presentaciones de información, pudiéndose dirigir a cualquier tipo de audiencia, por lo que deberá de fungir como instructor durante dicha actividad.

El BA durante la fase de evaluación colaborará con los equipos de trabajo, donde explorará las múltiples soluciones y planes que son parte de la propuesta al cliente, por lo que el BA deberá de utilizar su experiencia para identificar los riesgos que puedan tener una opción respecto de otra, un BA efectivo deberá de identificar, cuantificar y comunicar los riegos así como las incertidumbres que provenga del consejo a proveerse.

Mejores Practicas BA (Business Analysis)

Mejores Practicas de Análisis de Negocio (Business Analysis Best Practices)

Estás son el grupo de métodos y técnicas que a través de la experiencia y la investigación son utilizadas de manera consistente para obtener los mejores resultados, estás ha sido probadas y verificadas por un grupo de expertos en el dominio, estás prácticas son utilizadas como un medio de referencia para medir el desempeño así como la calidad de los entregables, sin embargo no existe mejor práctica que pueda cubrir los diferentes escenarios o situaciones, por lo hay de realizarse adaptaciones de las mismas(mejora continua).

Para el caso de las mejoras prácticas en para el Análisis de Negocio, se han publicado un sin fin de libros, artículos y ensayos coincidiendo en toda ves que hay que realizar una con junto de actividades que se enfoquen a recopilar, analizar, documentar y verificar las necesidades del Stakeholder.

El BABOK^® 2.0 (Business Analysis Body of knowledge) es una recopilación de mejores prácticas y las cuales se constituyen como estándares reconocidos a nivel global, con esté grupo de prácticas se pueden medir el nivel de conocimiento y habilidades de las personas que participan dentro del Análisis de Negocio.


Las practicas dadas en el BABOK^® se encuentran divididas en áreas de conocimiento, asociadas con las actividades y habilidades necesarias para su ejecución, en la siguiente figura se resumen las áreas de conocimiento que deben de ser aplicadas como parte de las mejores prácticas de Análisis de Negocio

Business Analysis Planing and Monitoring

Es el área de conocimiento que cubre como el analista determina cuales son las actividades necesarias para completar un esfuerzo de Análisis de Negocio. Esto cubre la identificación de los Stakeholders, la selección de técnicas, procesos y actividades para la administración de los requerimientos, las actividades que se realicen en estar área de conocimiento proporcionarán las reglas de ejecución para las siguientes actividades de análisis.

Elicitation (Recopilación de Requerimientos)

Es la actividad donde el analista deberá de recopilar y entender las necesidades claves de los stakeholder, el ambiente actual del negocio. El propósito es contar con una base de las necesidades del negocio que permitan definir el alcance de la iniciativa, asegurando que las necesidades sean las requeridas mas que las deseadas.

Requeriments Management and Comnunication

Describe como el analista deberá de manejar los conflictos, issues y controles de cambios, con el objetivo de asegurar que son comunicados todos los stakeholder y los miembros del equipo del proyecto estén en común acuerdo sobre la solución dada, además de proveer los procesos para el manejo de los requerimientos y las métricas a utilizarse para el avance de los requerimientos

Enterprises Analysis

Describe como el analista identifica las necesidades de negocio, refina y clarifica la definición de las necesidades halladas, además define, propone la solución en base a la cobertura de los requerimientos detectados, con los cuales habilitara a los equipos de proyecto la implementación de la solución.

Cabe mencionar el el análisis empresarial no es llevado a cabo por una sola persona, sino que es una colaboración multidisciplinaria (Arquitectura, Análisis, Desarrollo y Pruebas) en función que la solución que se provee sea factible y este alineada a los objetivos que busca el cliente, tiempo y esfuerzo.

Requirements Analysis

Describe las actividades a realizar durante la clasificación de los requerimientos, durante este análisis se deberá de bosquejar como los requerimientos son cumplidos o cubiertos por la propuesta de solución, para lo cual se apoyará de diferentes técnicas de modelado que permitan a los stakeholders entender, verificar y validar el cumplimiento de las necesidades claves del negocio.

Este análisis permite a los stakeholders tener una visión clara del estado actual del negocio y evaluar las recomendaciones de mejora que provee el analista en función de cubrir dichas necesidades

Underlying Competences

En esta práctica se describen las habilidades interpesonales que deberá de tener los Analistas de Negocio para poder realizar la ejecución efectiva de las prácticas anteriores.

Estas son :

Pensamiento Analítico, o lógico para abstraer el problema de dominio. (separación de responsabilidades)

Comportamiento (Confiabilidad, Efectividad, responsabilidad, Organización personal, Persuación Ética otras..)