01 201703 ba_lab_rm_iiba_it_ch_scope_creep_final

IIBA®, the IIBA® logo, BABOK® and Business Analysis Body of Knowledge® are registered trademarks owned by International Institute of Business

Analysis. CBAP® and CCBA® are registered certification marks owned by International Institute of Business Analysis. Certified Business Analysis

Professional, Certification of Competency in Business Analysis, Endorsed Education Provider, EEP and the EEP logo are trademarks owned by

International Institute of Business Analysis.

Eliminare il gap tra esigenze reali e requisiti espressi grazie alla Business Analysis Federico Maria Capo

IIBA® Italy Chapter

Marzo 2017

2

• Con SCOPE CREEP ci si riferisce, in genere, ad un PROGETTO che vede i suoi OBIETTIVI

ORIGINALI ESPANDERSI SENZA CONTROLLO mentre il progetto è in corso

• Come suggerisce il termine «creep: che avanza lentamente» è un PROCESSO SUBDOLO

che inizia con PICCOLI AGGIUSTAMENTI e finisce con PROGETTI che si ESTENDONO molto

più del tempo previsto o addirittura FALLISCONO ancora prima di completarsi, per l’incremento

di tempi e costi

Cos’è

Quali rischi comporta

Lo Scope Creep (1/2)

• Ha un impatto negativo sulle SCADENZE e sul BUDGET di progetto

• Comporta PERDITE FINANZIARIE nel caso in cui un progetto sia cancellato

• Determina INSODDISFAZIONE degli STAKEHOLDER

• Genera INEFFICIENZE per le continue RILAVORAZIONI

• Crea FRUSTAZIONE nel team di progetto

Più sinteticamente lo SCOPE CREEP

comporta una generale PERDITA del

VALORE della SOLUZIONE

3

A Analisi

Requisitazione

Definizione dello Scope di

Progetto

Elicitation Requirements

Analysis

Business Need

Definition

Lo Scope Creep (2/2)

Le principali CAUSE che portano allo SCOPE CREEP sono:

• ASSENZA di CHIAREZZA nella definizione dell’AMBITO del PROGETTO

• MANCANZA di REQUISITI essenziali (siano essi impliciti o espliciti)

• AGGIUNTA di FUNZIONALITÀ che NON contribuiscono al VALORE apportato dal Progetto

Quando può verificarsi

Perdita di Business Value + -

4

Il 45% circa delle FUNZIONALITA’ di un SOFTWARE, in media, non sono MAI UTILIZZATE

The 45% Disaster

Anche se il progetto è completato, lo

SCOPE CREEP può portare a

RISULTATI DISTANTI da quelli

EFFETTIVAMENTE NECESSARI,

erodendo il VALORE ATTESO dalla

SOLUZIONE

5

Perché la Business Analysis

Fonte: Standish Group (sulla base di 8000 progetti analizzati)

Più del 50% delle CAUSE di

FALLIMENTO dei progetti

ICT può essere ricondotto a

CARENZE di BUSINESS

ANALYSIS

1

2

3

4

5

6

8

7

Requisiti non completi

Stakeholder non coinvolti nell’analisi

Carenza di risorse

Aspettative irrealizzabili

Carenza di Governance

Change requests

Carenza di pianificazione

Non più necessario

13,1%

12,4%

10,6%

9,9%

9,3%

8,7%

8,1%

7,5%

CAUSE DEL FALLIMENTO DEI PROGETTI ICT

La BUSINESS ANALYSIS supporta le organizzazioni nella definizione del prodotto/servizio

atteso e nello sviluppo del "BETTER BUSINESS OUTCOMES", guidandole nel cambiamento

verso la giusta direzione

6

Lo Scope Creep nel BABOK®

Business Analysis Body of Knowledge® (BABOK® Guide) v3

•L’unico standard riconosciuto a livello mondiale per la pratica della BA

•La conoscenza collettiva di tutta la community di BA

•L'insieme di competenze e conoscenze richieste ad un BA professionista

7

Business

Analysis

Il BUSINESS ANALYSIS CORE CONCEPT MODEL™ è il FRAMEWORK CONCETTUALE alla base

della Business Analysis. Esso include tutti gli elementi di base di cui si essa si compone e il significato

stesso della Business Analysis

COSA FA LA BUSINESS ANALYSIS:

ATTRAVERSO UN’APPROFONDITA ANALISI E

COMPRENSIONE DEI BISOGNI, ANALIZZANDO

IL CONTESTO DI RIFERIMENTO E GLI SCENARI

ATTESI, LA BUSINESS ANALYSIS CONSENTE DI

IDENTIFICARE CIÒ DI CUI GLI STAKEHOLDERS

EFFETTIVAMENTE NECESSITANO,

INDIVIDUANDO LA SOLUZIONE CHE ABILITI IL

CAMBIAMENTO, ASSICURANDO IL

RAGGIUNGIMENTO DEL MAGGIOR VALORE

PER L’ORGANIZZAZIONE

Source BABOK® Guide – Version 3.0 - IIBA Italy Chapter Rome Branch elaboration

Il Framework concettuale della BA

8

I Requisiti secondo l’IIBA®

DESIGN

DESIGN DESIGN

ASSESS

OUTCOME

Business

Requirements

Perché lo

vogliamo?

Sono gli OBIETTIVI e gli ESITI che descrivono il

MOTIVO per cui un CAMBIAMENTO è stato

avviato

Le ESIGENZE degli

STAKEHOLDER che

devono essere

soddisfatte al fine di

assicurare il

RISPETTO dei

REQUISITI di

BUSINESS. Sono il

COLLEGAMENTO

tra le ESIGENZE di

business e le

SOLUZIONI che le

soddisfano

Stakeholder

Requirements

Quali bisogni

soddisfa?

Le FUNZIONALITÀ e le QUALITÀ che una

SOLUZIONE deve possedere per soddisfare

le esigenze degli stakeholder

Solution

Requirements

Cosa

vogliamo?

Transition

Requirements

A quali

condizioni?

Le FUNZIONALITÀ

che la soluzione deve

avere e le CONDIZIONI

che deve soddisfare

per facilitare la

TRANSIZIONE verso il

cambiamento, ma che

non saranno più

necessarie quando la

soluzione sarà messa

in campo

Definire e sviluppare la

soluzione a maggior valore

passa per la definizione di

4 TIPOLOGIE DI REQUISITI,

tra loro interconnessi

gerarchicamente


9

La Requirements Traceability

The purpose of Trace Requirements is to ensure that REQUIREMENTS and designs at

different levels are ALIGNED TO ONE ANOTHER, and to manage the effects of change to

one level on related requirements. - Business Analysis Body Of Knowledge v3 -

La TRACEABILITY assicura che la SOLUZIONE che

si va ad implementare sia CONFORME AI REQUISITI

DI BUSINESS ed è di supporto nelle attività di scope,

change, risk, time, cost e communication

management.

E’ inoltre funzionale alla rilevazione di buchi funzionali

(requisiti non coperti da soluzioni) o per identificare

quelle funzionalità che non sono supportate da alcun

requisito.

10

Input

Ingredienti

Output

Business Analysis

Aree di Conoscenza

Task

Il BABOK classifica le attività di Business Analysis in 6

AREE di CONOSCENZA (o KNOWLEDGE AREA),

all’interno delle quali sono descritti 30 TASK

Per essere eseguito il TASK necessita di:

• Tutte le INFORMAZIONI NECESSARIE

per AVVIARE un TASK

• Possono essere il RISULTATO di

precedenti ATTIVITÀ di BA oppure

provenire dall’ESTERNO

• NON è NECESSARIO che l’input sia

COMPLETO o nel suo stato finale per

iniziare un task

• ELEMENTI: concetti chiave

per comprendere la natura del

task

• LINEE GUIDA / STRUMENTI:

risorse che possono essere

necessarie per eseguire il task

• TECNICHE: utilizzabili per

eseguire il task

• STAKEHOLDER: lista

generica di possibili attori

coinvolti, a vario titolo, nel task

• Il RISULTATO dell’applicazione del

TASK

• Può essere un DELIVERABLE o

PARTE di un deliverable più ampio

• La sua forma può dipendere da molti

fattori (iniziativa, standard applicabili,

esperienza del BA)

• NON è NECESSARIO che sia

COMPLETO o nel suo stato finale

Le Aree di Conoscenza (KA) della BA


11

Lo Spettro del Valore della BA

Le AREE DI CONOSCENZA della BA consentono di AVANZARE lungo lo SPETTRO del VALORE, dal

POTENZIALE all’ATTUALE, AZZERANDO lo SCOPE CREEP

Strategy

Analysis

Requirements Analysis &

Design Definition

Solution

Evaluation

Business Analysis Planning & Monitoring

Need Solution Scope Requirements Design Proof of Concept /

Prototype

Pilot /

Beta

Operating

ACTUAL

VALUE

POTENTIAL

VALUE

Business

Requirements

Solution

Requirements

Transition

Requirements Stakeholder

Requirements

Elicitation and Collaboration

Requirements Life Cycle Management

Core KAs

Support KAs

V


12

Le relazioni tra le KA


13

Le Aree di Conoscenza «core»


Solution

Strategy

Analysis Requirements Analysis & Design Definition

Solution

Evaluation

Task

Obiettivo

Identificare i BISOGNI di

un’ORGANIZZAZIONE di

rilevanza TATTICA e/o

STRATEGICA per

indirizzarli attraverso la

STRATEGIA di

CAMBIAMENTO più adatta

Business

Requirements Solution

Requirements

Transition

Requirements Stakeholder

Requirements

• SPECIFICARE e MODELLARE i requisiti e il design della soluzione

• STRUTTURARE ed ORGANIZZARE i requisiti

• VALIDARE e VERIFICARE le informazioni raccolte

• IDENTIFICARE le possibili SOLUZIONI alternative in risposta ai bisogni

individuati, stimandone il VALORE POTENZIALE

TRASFORMARE i BISOGNI iniziali nella SOLUZIONE a maggior VALORE,

attraverso processi iterativi ed incrementali

• Stabilire gli OBIETTIVI di

BUSINESS

• Definire IMPATTI AS IS

• Identificare la

SOLUZIONE a

MAGGIOR VALORE

• Evidenziare i RISCHI e

possibili EFFETTI

• GAP ANALYSIS e piano

di CAMBIAMENTO per

ciascuna iniziativa

• Definizione delle METRICHE

di misurazione del VALORE

della soluzione

• MISURAZIONE delle

PERFORMANCE

• Rilevazione di LIMITI per il

VALORE ATTESO

• Raccomandazione di

INTERVENTI in ottica di

MIGLIORAMENTO

CONTINUO

Valutare le PERFORMANCE

ed il VALORE PRODOTTO

dalla SOLUZIONE in USO

per segnalare la RIMOZIONE

di BARRIERE e VINCOLI che

ostacolino il raggiungimento

dei LIVELLI ATTESI

14

Le Aree di Conoscenza di supporto


Business

Requirements

Solution

Requirements

Transition

Requirements

Stakeholder

Requirements

Solution

Req

uir

emen

ts L

ife

Cyc

le M

anag

emen

t

Obiettivo

Attività

Elic

itat

ion

an

d C

olla

bo

rati

on

Assicurare un

CONTROLLO sui

REQUISITI affinchè siano

sempre ALLINEATI fra di

loro, siano allineati con il

design della soluzione e

siano in essa INCLUSI

• TRACCIARE (traceability) i

requisiti

• Verificare

l’ACCURATEZZA e

l’assenza di INCOERENZE

fra i requisiti e fra i requisiti

ed il design della soluzione

• RI-UTILIZZARE i requisiti

per usi futuri

• PRIORIZZARE i requisiti

• VALUTARE le RICHIESTE

di CAMBIAMENTO, in

ottica di allineamento

tattico-strategico

• FAR APPROVARE i

requisiti

Bu

sin

ess

An

alys

is P

lan

nin

g &

Mo

nit

ori

ng

OTTENERE

INFORMAZIONI e

verificarne l’esatta

COMPRENSIONE,

COMUNICANDO

opportunamente con tutti

gli attori interessati

• PREPARARE le sessioni

di elicitazione

• CONDURRE le sessioni

• CONFERMARE le

evidenze emerse

• COMUNICARE le

evidenze raccolte

• COLLABORARE con gli

ATTORI INTERESSATI

per ottimizzare tutte le

attività descritte ai punti

precedenti

ORGANIZZARE

e COORDINARE tutte

le ATTIVITA’ di BA

condotte dai BUSINESS

ANALYST e

nell’interazione con gli

STAKEHOLDER

• PIANIFICAZIONE di tutte

le ATTIVITÀ di BA, dalla

scelta della metodologia

alle singole ATTIVITA’,

TASK e DELIVERABLE

• ANALISI degli

STAKEHOLDER e

PIANIFICAZIONE del

loro ENGAGEMENT

• PIANIFICAZIONE delle

componenti di BA a

supporto della

GOVERNANCE

• PIANIFICAZIONE delle

modalità di GESTIONE

delle INFORMAZIONI

• Identificazione di AREE

di MIGLIORAMENTO

delle attività di BA

15

Flow Chart /

Activity Diagram

venti oncetti

(Entità) e

Relazioni

Specify,… …and Define Requirements

Architecture …Model,…

Roles / Profiles

Matrix

Entity-

Relationship

Model / Class

Diagram

Events Matrix

Business Rules

Matrix

….

Il Modello «PURCE» per lo sviluppo dei Requisiti Funzionali

U

egole di

Business R

P

C E

P

U

egole di

Business R

oncetti

(Entità) e

Relazioni

C

venti E

Soluzione


16

Security

Compatibility

Usability

Relaibility

Maintainability

Performance

Efficiency Portability

I Requisiti non Funzionali per l’IIBA®

Extensibility

Localization

Certification

Compliance

Service Level

Agreement

Scalability

Capacità della soluzione di gestire incrementi

della quantità di lavoro svolto

Capacità della soluzione di essere allineata

al vincoli regolatori/legali di una data

giurisdizione

Capacità della soluzione di estendere le

proprie funzionalità

Capacità della soluzione di essere adattata e

di operare in contesti locali differenti (lingua,

cultura, etc.)

Capacità della soluzione di soddisfare

determinati standard industriali

Capacità della soluzione di

assicurare determinati livelli di

servizio per l’organizzazione

ISO/IEC

25010:2011


17

Come esprimere i Requisiti non Funzionali

NFR

Trattando ASPETTI

QUALITATIVI, molto

spesso è più facile

esprimerli in modo

INDEFINITO

NFR troppo STRINGENTI

possono far lievitare

facilmente i COSTI di una

soluzione

Potendo trattare ASPETTI

più TECNICI, possono

essere più DIFFICILI da

ESPRIMERE per un

Business Analyst

E’ necessario

COLLABORARE con gli

ATTORI più TECNICI nella

fase di declinazione dei

NFR

Devono essere espressi in

funzioni delle REALI

NECESSITÀ, mediando con

gli attori interessati il costo /

opportunità

Ma come tutti i requisiti,

devono essere elaborati

con i GIUSTI ATTORI…


devono essere

PRIORIZZATI


devono essere TESTABILI

Provare ad esprimerli

quantificandoli in base a

possibili MISURE

CORRELATE alla categoria

di NFR espresso

«Il sistema deve

fornire il 90% delle

risposte in 2 secondi»

«Il sistema deve fornire

il 90% delle risposte

entro i 5 secondi»

«Il sistema deve fornire

il 90% delle risposte in

brevissimo tempo»

• Creare una stretta

CORRELAZIONE tra

Requisiti Funzionali e

Requisiti Non Funzionali, in

modo che i secondi siano di

aiuto alla migliore

declinazione dei primi;

• Considerare sempre i NFR

come una CHECKLIST da

affiancare ai Requisiti

Funzionali.

«Il sistema deve rispondere velocemente»

C.O.M.P.Ra.S.Ti

C.L.A.S.S.E. C.

• Compatibility

• Operability

• Maintainability

• Performance effic.

• ReliAbility

• Security

• TransferabIlity

• Compliance

• Localization

• Availability

• Scalability

• Service level agr.

• Extensibility

• Certification

Come ricordarli tutti?

18

I BUSINESS ANALYST gli «ARCIERI» del cambiamento e le FRECCE al nostro arco!

Increase Consistency

Improve Information Access

Automate, where possible

Reduce complexity

Innovate, uncovering new capabilities

Remove Redundancy

Eliminate Waste

Gli attori chiave per il cambiamento


19

Spazio al Case Study