PMI EMEA Congress 2011 - Session PRJ11

Generating Opportunities from Constraints

Ethics for Project Success

Michela Ruffa, PMP© - Director at Large – PMI © Northern Italy Chapter

Stefano Setti, PMP© - Director at Large – PMI © Northern Italy ChapterDario Morandotti

Milano, 9 Settembre 2016

Requirements how toTracciare i requisiti, definire lo scope e gestire gli

stakeholders

Raccontare la trasformazione da metodi

tradizionali ad “Agile” e discutere le lezioni apprese

• Cosa fa GE POWER e cosa fa GE POWER Digital Engineering

• Video introduttivo su requisiti, esperti ed incomunicabilità

• Agile in 1 pagina

• Con che approcci/metodi/strumenti lavora GE POWER Digital Engineering su requisiti, stakeholders ed implementazione progetti

• Come sta avvenendo la trasformazione, successi e sfide

• 3 risposte alle 3 domande chiave della giornata

• In sintesi, le lezioni apprese: la transizione è facile da capire ed amare ma difficile da eseguire

• Discussione (se rimane tempo)

Il vostro speaker oggi

Program Manager @ GE POWER – Digital Engineering

Product Lifecycle Management (PLM), New Product Develoment & Innovation Management, Plant Engineering

Business & Information Technology

PMI e PMP© dal 2005

www.linkedin.com/in/dariomorandotti

4

GE POWER>$30B Revenue ~80,000 employees >120 countries

GAS

POWER

SYSTEMS

POWER

SERVICES

STEAM

POWER

SYSTEMS

DISTRIBUTED

POWER

GE HITACHI

NUCLEAR

POWER

WATER

PROCESS

Schenectady,

NY, USA

Baden,

SwitzerlandBaden,

Switzerland

Jenbach,

Austria

Wilmington,

NC, USA

Trevose,

PA, USA

5

La missione di GE POWER – Digital Engineering è

supportare end-to-end lo sviluppo di nuovi prodotti e

progetti

• Utenti distribuiti nel mondo (GE POWER, GE Renewables)

• Applicazioni, dati, processi, infrastruttura

• Da custom specifici a large enterprise (es. PLM)

• Nuovi sviluppi ed evoluzione continua dell’esistente – lifecycle delle applicazioni

(molte con vita > 10 anni)

PLM (Enovia)

Digital Manufacturing (Delmia)

Plant Engineering (PDMS/E3D, SmartPlant)

CAD/CAM (Catia, NX, AutoCAD)

High Performance Computing & CAE (Ansys, LS-Dyna, Fluent, ecc.)

VR/AR Project Execution

Management (Primavera)

Engineering Document Management

Minimum Viable

Product

The Expert

Un noto (disponibile su YouTube) breve filmato di 7 minuti

sull’incomunicabilità durante le discussioni sui requisiti

Gli “stakeholders” di GE POWER – Digital

Engineering sono differenziati. Trovare le

comunalità e concordare le priorità rimane una

sfida

• Vasta linea di prodotti (Gas, Steam, Services, componenti ed impianti,

automazione, ecc)

• Diverso approccio di business, processi, priorità

• Dispersi geograficamente

• A volte i requisiti provengono direttamente dai clienti finali di GE

POWER

• Requisiti spesso in contrasto tra diversi stakeholders, o totalmente

specifici

Agile e Scrum in 1 pagina …

Agile Manifesto & Twelve Principles

Minimum Viable

Product

L’approccio Agile offre sostanziali benefici

ma anche sfide culturali ed operative

SFIDE

Limitato controllo manageriale

Limitata visibilità sul completamento del progetto(numero di iterazioni)

Metriche di misurazione non familiari (es. Burnout chart)

Cambiamento della cultura di team, self-organizzazione

L’approccio dà il meglio con team stabili e relazioni vis-à-vis

Requisiti: necessita “user stories” che stiano in una iterazione

BENEFICI

63% dei team migliore qualità 88% dei team maggiore

produttività 37% migliore time-to-market 29% costi globali ridotti del

progetto Successo in progetti di medio-

grandi dimensioni:

WATERFALL 11% successo, 60% “challenged”, 29% “ failed”

AGILE 39% successo, 52% “challenged”, 9% “ failed”

Fonte: Innotas, Standish Group

L’evoluzione nell’approccio GE POWER Digital

Engineering verso requisiti ed implementazione

Fino al 2011 2011-2015 Dal 2015

Strumenti per documentare irequisiti

Excel, WordExcel, Word, SharePoint, Redmine

Redmine, Agile Central

Modalità di raccolta e discussione dei requisiti

Workshops Workshops Backlog grooming

Tipologia di requisiti

Funzionali, infrastrutturaliFunzionali, infrastrutturali, amministativi

Funzionali, infrastrutturali,performance, amministrativi, mantenibilità

Approvazionedei requisiti

Processo non formale, “Minute of meeting”

Processo formale, firma di documenti

User stories direttamente nellemani degli stakeholders

Evoluzione(modifica) dei requisiti

RaraOccasionale, processoformale di ri-approvazione

Continua, inclusanell’evoluzione del backlog

Relazione con stakeholders

Occasionale Occasionale, negoziativaPer lo più collaborativa (inclusinel team Agile)

L’evoluzione nell’approccio GE POWER Digital

Engineering verso requisiti ed implementazione

Fino al 2011 2011-2015 Dal 2015

Regression test Limitati Manuali Automatizzati (in via di …)

Sviluppo eprototipi

Tradizionale sequenziale, pochi prototipi, lunghitempi tra defizione dei requisiti e rilascio del sistema

Tradizionale sequenziale, pochi prototipi, lunghi tempi tra defizione dei requisiti e rilascio del sistema

Agile, frequenti rilasci

Rifacimentidovuti a malintesi surequisiti

ElevatiPochi ma tali da influenzaretempi e costi

Accettati ed inclusi nel backlogAgile, ri-prioritizzazione

% progettiWaterfall-Agile

100% Waterfall

GE Legacy inizio Agile dal 2014 ALSTOM Legacy qualchetentativo Agile

GE Legacy 30%-70%, target2017 “100% Agile”ALSTOM Legacy 75%-25%, target 2017 60% Agile

Successo ed insuccesso

Scopo -> parzialeTempi -> spesso ritardiCosti -> spesso oltre il budget

Scopo -> parziale od “on scope”Tempi -> spesso qualcheritardoCosti -> spesso in budget

Scopo -> evolutivo, MVP “minimum viable product”Tempi -> più rapidiCosti -> spesso in budget, focus sul valore

Tools: Redmine

Tools: Agile Central (Rally)

Come è composta una buona user

story

As … [utente e ruolo]

I want to … [oggetti, azioni e dati]

So that … [risultati ed implicazioni]

Why … [motivazioni e benefici]

Done when … [criteri di accettazione]

La trasformazione Agile in corso avviene

con diverse modalità

Dai requirements alle userstories, una modalità che aiuta la collaborazione con gli stakeholders

Flessibilità, non applicato a tutti i progettiPartiti da quelli più adatti (es. correzione errori PLM)

Sistemi più dinamici (Rally) per raccogliere ed elaborare i requisiti, invece che la sola documentazione

Coaching oltre a formazione ed on-boardingTest & adapt sulle reazioni stakeholders

Reso visibile il nuovo paradigma

Riconoscere che è difficile pianificare con accuratezza all’inizio

Focus sull’evoluzione più che sulla completezza

Raccogliere e discutere i requisiti

nell’approccio Agile è più facile?

Epic -> Theme -> User Story. Un percorso che facilita la conversazione sui reali bisogni

“Spezzare” le user stories in modo che possano essere sviluppate in una iterazione – e quindi che i risultati dello sviluppo siano subito visibili

Criteri di accettazione del prodotto finale, complementari ai requisiti

Togliere l’ “assillo della completezza”: riconoscere che è difficile pianificare ed i requisiti possono evolvere

Backlog grooming (coltivare i requisiti)

Alla ricerca del MVP – Minimum Viable Product

Empatia – facilitata da una relazione continua e vis-à-vis con gli stakeholders

Successi – cosa sta funzionando bene e

Sfide – miglioramenti futuri

SFIDE

• I cambiamenti sono a 360 gradi

• Tendenza a ricadere nel paradigmasequenziale o sovra-complicazione

• Grandi progetti con grandi blocchi, imparare a definire user stories adatte

• Disponibilità di buoni Product Owners

• Tendenza a test di accettazionesolo alla fine dello Sprint

• OK Agile ma ancora difficile mettere in produzione

SUCCESSI

• Scrum “ceremonies” (attività) –poche ma di facile apprendimento, team più disciplinato

• Rally guida bene la definizione dei requisiti

• Dalla prima (incerta) espressionedel requisito al raffinamento –collaborazione tra il team di sviluppo e gli stakeholders con diverse viste dei requisiti

• Planning iterativo (day-week-3 months – year) aiuta nelle priorità

• Visibilità del risultato - iniziatocon progetti semplici , es. correzioni errori PLM

Tre risposte alle tre domande chiave della

giornata

E’ possibile soddisfare le continue richieste degli

Stakeholders ed i frequenti cambiamenti di specifiche

senza compromettere il risultato finale?

• Agile nasce (anche) per questo

• Chiude il gap tra specifiche in evoluzione e

disponibilità del risultato finale

Tre risposte alle tre domande chiave della

giornata

Esiste un punto di equilibrio tra il permettere un

cambiamento continuo e impedirlo completamente?

• Valore e budget parametri chiave per le decisioni

• La realtà insegna che il processo iterativo – dopo una

fase di sperimentazione – tende a convergere sul

valore

Tre risposte alle tre domande chiave della

giornata

Ma soprattutto come ci si assicura che il risultato sia ciò

di cui lo Stakeholder ha effettivamente bisogno?

• MVP ed approccio iterativo una risposta sperimentata

• Il minimo set di funzionalità usabili che ha un valore

tangibile viene messo a disposizione. E su quello di

itera / incrementa

• Sono gli stakeholders che decidono cosa ha valore ma

è il team che lo mette a disposizione

In sintesi, le lezioni apprese:

Agile si sta rivelando una strada di successo per

la maggiore soddisfazione degli stakeholders,

anche in organizzazioni complesse come GE

MVP – Minimum Viable Product

Aspetti “fun” per avere maggiore coinvolgimento degli stakeholders

Facile da capire e da amare, ma difficile da eseguire – si ricade nei vecchi modelli

Facile da sperimentare ed apprendere - non sottostimare le capacità di apprendimento dei team

In sintesi, le lezioni apprese:

la trasformazione, anche in GE POWER, è un

viaggio (in corso), dare agli stakeholders ed al

team il tempo di maturare

“Think big, execute small but fast and incrementally”

Non pretendere 100% da subito, ma aderire alla filosofia dell’approccio: cambiamento del paradigma - focus dal costo al valore

“Culture DOESN’T eat strategy (approach) for lunch”.Progredire, in parallelo, sulla maturità delle pratiche, processi, approcci e strumenti

Preparazione, buy-in, on-boarding, rimuovere gli ostacoli: tutto ok ma ogni progetto/team ha le sue sfide