Ogni modello PMLC usa gli stessi cinque gruppi di processi. Ecco che cosa fa ciascuno, nelle parole del corso, e quali processi contiene.
| Gruppo | Definizione |
|---|---|
| Scoping / Initiating | Sviluppa e ottiene l'approvazione di una «dichiarazione generale» riguardante gli obiettivi e il business value del progetto. |
| Planning | Identifica le attività che devono essere svolte per implementare i requisiti e completare il progetto, stima tempo, costi e risorse necessarie e ottiene l'approvazione del piano. |
| Launching / Executing | Seleziona il personale da coinvolgere nel team, stabilisce le regole operative del team e aiuta il team a lavorare assieme per completare con successo il progetto. |
| Monitoring & Controlling | Verifica lo stato di avanzamento del progetto rispetto al piano, risponde alle richieste di modifica e risolve le situazioni problematiche che emergono, per garantire progresso e successo. |
| Closing | Assicura che siano stati soddisfatti tutti i requisiti del committente, provvede alla consegna dei deliverable e decreta la fine formale del progetto. |
Le liste dei processi contenuti in ciascun gruppo sono la spina dorsale dell'intero corso: i capitoli 6–11 non fanno altro che percorrerle una per una. Vale la pena impararle nell'ordine in cui compaiono, perché l'ordine è già una risposta alla domanda «da dove comincio?».
Contrariamente a quanto si potrebbe pensare, i process group non corrispondono al Project Management Life Cycle. I process group possono essere mappati in diverse modalità, dando origine a PMLC anche articolati e complessi.
Due conseguenze pratiche:
Le aree di conoscenza definiscono delle aree di specializzazione dei processi di gestione di un progetto. Il PMBOK ne individua 9+1: la decima, Stakeholder Management, è stata inserita a partire dalla quinta edizione.
| # | Area di conoscenza | In una riga |
|---|---|---|
| 1 | Integration Management | Collega tra loro i deliverable perché, integrati, forniscano la soluzione. |
| 2 | Scope Management | Distingue i desideri dai bisogni e struttura i requisiti (RBS). |
| 3 | Time Management | Stima durate e distingue durata da quantità di lavoro. |
| 4 | Cost Management | Stima, mappa e controlla i costi. |
| 5 | Quality Management | Pianifica, assicura e controlla la qualità di prodotto e processo. |
| 6 | Human Resources Management | Profili, competenze e motivazione delle persone. |
| 7 | Communications Management | Il passaggio di informazione che deve essere compresa e accettata. |
| 8 | Risk Management | Identifica, valuta, mitiga e monitora i rischi. |
| 9 | Procurement Management | Sollecita, valuta, seleziona, contrattualizza e gestisce i fornitori. |
| +1 | Stakeholder Management | Identifica e coinvolge attivamente chi influenza o è influenzato dal progetto. |
La gestione dell'integrazione riguarda i processi che consentono di effettuare il collegamento tra i diversi deliverable, che integrati tra loro forniscono la soluzione del progetto. I processi coinvolti sono sette: sviluppo del Project Overview Statement; sviluppo dello Scope Statement; sviluppo del Project Plan; avvio dell'implementazione (esecuzione); monitoraggio e controllo del lavoro svolto; controllo integrato dei cambiamenti; chiusura del progetto.
L'Integration Management è l'unica area che tocca tutti e cinque i gruppi di processi: è, letteralmente, la cucitura tra i gruppi. Non a caso i suoi sette processi ricalcano l'intero ciclo di vita.
Il punto di partenza è una frase che ritornerà, identica, nel capitolo 6: «Cosa il cliente vuole può non essere ciò di cui il cliente ha bisogno.» Desideri e bisogni si sovrappongono solo in parte, ed è compito del project manager far coincidere le due cose.
Gli strumenti di quest'area sono due, entrambi ripresi in dettaglio nel capitolo 6:
Il cuore del Time Management è una distinzione che sembra pedante e non lo è: durata (duration, il tempo di calendario) e quantità di lavoro (labor, l'effort) non coincidono.
Applica le assunzioni del modello a una stima di lavoro e osserva la durata di calendario che ne risulta.
Per stimare correttamente la durata delle attività si considerano: somiglianze con altre attività; dati storici; pareri di esperti; la Delphi technique; la three-point technique; la wide-band Delphi technique. Il dettaglio di questi metodi è nel capitolo 8.
Per stimare la durata di un'attività è necessario definire quante risorse saranno allocate all'attività e stimare il tempo/uomo richiesto a ciascuna risorsa per eseguirla. Durata e risorse non sono indipendenti: è per questo che la stima va sempre fatta sulle due grandezze insieme.
I processi di gestione dei costi devono essere applicati sia durante la pianificazione sia durante l'esecuzione.
| Voce di costo | Dettaglio |
|---|---|
| Costo della manodopera | Costo dovuto alla posizione; costo del singolo lavoratore. |
| Beni strumentali | Capital equipment. |
| Servizi appaltati | Contracted services. |
| Spese di trasferta | — |
I due tipi di qualità sono quelli già introdotti nel capitolo 3 — qualità del prodotto (riferita al deliverable) e qualità del processo (riferita al processo di gestione del progetto). Entrambe dipendono da tre aspetti:
La gestione della qualità considera tre processi fondamentali.
Determina gli standard di qualità rilevanti per il progetto e cosa è necessario fare per soddisfarli.
Input: fattori ambientali esterni (regole nazionali o internazionali, standard, linee guida riconosciute); fattori ambientali interni (politiche, procedure e linee guida aziendali, dati storici, lezioni imparate da progetti passati); Project Overview Statement; Project Management Plan.
Il Quality Plan documenta: come le politiche per la qualità devono essere soddisfatte; le metriche che saranno usate per misurare la qualità; un programma di miglioramento dei processi.
Contempla le attività necessarie per garantire il rispetto del piano di qualità — cioè l'impiego dei processi previsti nel Quality Planning — e che i requisiti di qualità siano soddisfatti.
Può prevedere: Quality Audits (verifica della qualità); Process Analysis (analisi dei processi); Project Quality Management Tools.
Prevede il monitoraggio delle performance del progetto per stabilire la conformità agli standard di qualità prefissati, e definisce le azioni da intraprendere se non vi è conformità con alcuni standard. Per eseguirlo si possono usare template, processi e strumenti specifici per la gestione della qualità.
I tre processi rispondono a tre domande diverse: planning = quali standard valgono qui; assurance = stiamo seguendo i processi che abbiamo dichiarato; control = i risultati sono conformi. Si può fare bene l'assurance e fallire il control (processo corretto, risultato fuori standard) e viceversa.
Il team può essere organizzato in numerosi modi — il surgical team, lo Scrum team del capitolo 2 — ma si possono individuare dei profili chiave: Developer co-manager, Client co-manager, Core Team, Task Leaders, Team Members. Per ogni componente devono essere definite con buona accuratezza conoscenze, abilità e competenze.
Nota anche come Two-Factor Theory, distingue i fattori che motivano da quelli che, se mancano, demotivano senza però motivare quando ci sono.
| Motivators | Hygiene Factors |
|---|---|
| Realizzazione · Riconoscimento · Progressioni di carriera e crescita professionale · Responsabilità · Il lavoro stesso | Politiche aziendali · Pratiche amministrative · Condizioni di lavoro · Supervisione tecnica · Relazioni interpersonali · Sicurezza del lavoro · Salario |
Da un'indagine condotta da Couger è emerso un possibile ordine di priorità dei fattori motivazionali: il lavoro stesso; opportunità di realizzazione; opportunità di progressione di carriera; salario e benefit; riconoscimento; crescente responsabilità; supervisione tecnica; relazioni interpersonali; sicurezza del lavoro; condizioni di lavoro; politiche aziendali.
Confrontate i due elenchi: il salario è un hygiene factor per Herzberg ma sale al quarto posto in Couger, mentre il lavoro stesso è primo in entrambi. È la ragione per cui il job design — cosa faccio tutti i giorni — è la leva più forte che un project manager ha in mano.
Diversi fattori motivazionali sono direttamente controllati o influenzati dalle azioni del project manager:
La comunicazione è un processo che consiste nel passaggio di una informazione da una persona a un'altra, che la deve comprendere. Quattro condizioni: l'informazione deve essere trasmessa correttamente; un messaggio inviato è un messaggio ricevuto; l'informazione deve essere compresa dal destinatario; l'informazione deve essere accettata dal destinatario.
Il ciclo di vita del risk management ha quattro fasi, ciascuna con le proprie domande.
Dopo aver identificato i rischi è necessario valutare la probabilità che l'evento avverso associato si verifichi e l'impatto sul progetto. Gli eventi identificati che possono avere un impatto negativo costituiscono i cosiddetti risk driver, che possono essere prioritizzati in base al loro impatto atteso: probabilità × impatto effettivo.
Un evento che ha probabilità dell'1% e produce una perdita di 50.000 euro ha un impatto atteso di 0,01 × 50.000 = 500 euro. Due corollari: se un rischio ha un impatto atteso irrilevante può essere ignorato; e se un evento è certo, non ha senso gestire il corrispondente rischio, perché se non c'è probabilità allora non c'è rischio — è un problema, non un rischio.
Imposta probabilità e perdita e osserva l'impatto atteso e la zona di azione.
| Modalità | Come funziona |
|---|---|
| Statico | La valutazione viene svolta all'inizio del progetto, durante il planning. |
| Dinamico | La valutazione svolta durante il planning viene aggiornata durante l'avanzamento. Man mano che le attività vengono eseguite si acquisiscono nuove informazioni, utilizzabili nella stima di probabilità e impatto di ciascun rischio. Consente una gestione migliore del rischio. |
Il Risk Matrix Tool incrocia le categorie di rischio (Technical, Project Management, Organizational, External) con gli elementi dello scope triangle (Scope, Time, Cost, Quality, Resources). Da questa griglia nasce il template di identificazione e valutazione, con colonne: Risk Category, Scope Triangle, Event #, Event, Y/N, Prob., Impact, Priority, Mitigate.
| Categoria | Elemento | ID | Evento (esempi dal template) |
|---|---|---|---|
| Tech | Scope | TS01 | Available HW/SW technology limits scope |
| Tech | Scope | TS02 | New technology does not integrate with old |
| Tech | Time | TT01 | Integrating technologies impacts schedule |
| Tech | Cost | TC01 / TC02 | Unexpected need to acquire hardware / software |
| Tech | Quality | TQ01 | Technology limits solution performance |
| Tech | Res | TR01–TR03 | New/unfamiliar technology; inadequate software sizing; inadequate hardware sizing |
| Proj Mgt | Scope | PS01 | Senior scope change request too significant |
| Proj Mgt | Time | PT01–PT04 | Schedule too aggressive; interproject dependencies compromise schedule; task duration estimates too optimistic; difficulty scheduling meetings |
| Proj Mgt | Quality | PQ01 | Inaccurate assumption |
Per la valutazione quantitativa si usa il Quantitative Risk Assessment Worksheet: righe = attività, colonne = risk driver, metrica 1–3 (alcune organizzazioni usano scale 1–5 o 1–10).
Non c'è nulla che possa essere fatto per mitigare il rischio. L'unica opzione disponibile è accettare il rischio e sperare che non si verifichi l'evento associato.
Il piano del progetto può essere modificato per eliminare la situazione che produce il rischio.
Contingency planning: stabilisce cosa deve essere fatto in futuro, se l'evento avverso si verifica.
Stabilisce cosa deve essere fatto subito per minimizzare l'impatto dell'evento avverso, se si verifica.
Consiste nel trasferire ad altri l'impatto dell'evento avverso: polizze assicurative, ricorso a conto terzi.
La differenza fra contingency planning e mitigate è il tempo verbale: la contingency dice cosa faremo se succede, la mitigation dice cosa facciamo ora perché, se succede, faccia meno male. Confonderle significa scrivere piani che nessuno esegue.
Lo strumento è il Risk Log, le cui voci sono: ID #, Risk Description, P (probabilità), I (impatto), Risk Owner, Action to be Taken, Outcome.
Il ciclo di vita dell'approvvigionamento ha cinque stadi in sequenza: Vendor Solicitation, Vendor Evaluation, Vendor Selection, Vendor Contracting, Vendor Management.
L'RFP è un documento da inviare ai vendor potenzialmente interessati. Contiene tutti i dettagli necessari ai vendor per capire se possono soddisfare le richieste, e deve essere molto chiaro per permettere a ciascuno di rispondere velocemente ed efficacemente. Solitamente è preparato dal Procurement Office ed è supervisionato da un ufficio legale, perché può costituire la base per il futuro contratto.
Nella stesura dell'RFP bisogna considerare anche tutti gli aspetti che potrebbero stimolare i vendor a partecipare. Termini troppo stretti o condizioni poco convenienti per la controparte potrebbero scoraggiare la partecipazione. Perché lo vogliamo evitare? Perché meno offerte significa meno concorrenza — e quindi condizioni peggiori proprio per chi ha scritto l'RFP.
Contenuto dell'RFP: introduzione; business profile; descrizione del problema/opportunità; POS e/o RBS (opzionali); stime dei costi, dei tempi e del prezzo previsto (ordine di grandezza); criteri utilizzati per valutare le offerte; descrizione delle responsabilità del vendor; dettagli amministrativi del contratto; istruzioni per i vendor; riferimenti e contatti.
| Strumento | Quando serve |
|---|---|
| Request for Information (RFI) | Può essere una semplice lettera o un vero questionario, da inviare a possibili vendor quando non si conosce il mercato di riferimento e si fatica a identificare i destinatari dell'RFP. Obiettivo: selezionare i vendor che potrebbero essere interessati. |
| Pubblicità | Canali specifici (associazioni, siti web, mailing list) per pubblicizzare l'opportunità e richiamare l'interesse. |
| Fornitori abituali | Contattare i vendor con cui si è collaborato con successo in passato. |
| Fiere o business meeting | Partecipare a eventi del settore per conoscere i possibili fornitori disponibili sul mercato. |
Il Forced Ranking fa esprimere a più consulenti una graduatoria dei vendor; si sommano i ranghi (Rank Sum) e si ricava il Forced Rank. Il Paired Comparison confronta ogni vendor con ogni altro: 1 se il vendor di riga batte quello di colonna, 0 altrimenti; la somma di riga determina il rango.
Per ogni coppia scegli il vendor che preferisci: la matrice e i ranghi si aggiornano da soli.
| Fase | Contenuto |
|---|---|
| Vendor Selection | Si seleziona il vendor «vincitore». L'esito può essere: No Award — nessun vendor soddisfa i requisiti minimi, è necessario ripetere la procedura dall'inizio o rinunciare; Single Award — è stato selezionato un fornitore unico; Multiple Awards — nessun fornitore poteva soddisfare tutti i requisiti, ma due o più vendor possono dividersi il lavoro e soddisfarli. |
| Vendor Contracting | La negoziazione parte da una delle due situazioni (Single o Multiple Awards) e porta alla definizione dei termini contrattuali definitivi. |
| Vendor Management | Definire nelle fasi iniziali della collaborazione i rapporti, anche informali, con il fornitore, valutando, stabilendo e accettando le modalità di gestione e le aspettative reciproche; monitorare progressi e performance; eseguire i test per l'accettazione (collaudo); gestire la transizione tra il fornitore e il cliente finale. |
Le definizioni di stakeholder raccolte dal corso (estratte da un articolo pubblicato dal PMI) mostrano quanto il concetto sia largo.
| Fonte | Definizione |
|---|---|
| Merriam-Webster | One that has a stake in an enterprise. One who is involved in or affected by a course of action. |
| The Scrum Primer (Deemer et al. 2010) | Someone with an interest in the outcome of a project, either because they have funded it, will use it, or will be affected by it. |
| BABOK Guide (IIBA) | A group or person who has interests that may be affected by an initiative or have influence over it. |
| PRINCE2 Glossary | Any individual, group or organization that can affect, be affected by, or perceive itself to be affected by, an initiative (programme, project, activity, risk). |
| PMBOK | A stakeholder is an individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project. |
Gli stakeholder includono tutti i membri del team di progetto e tutte le entità interne ed esterne all'organizzazione interessate al risultato. Il team identifica gli stakeholder interni ed esterni, sia quelli positivi sia quelli negativi, con cui collaborerà per determinare i requisiti del progetto e le aspettative di tutte le parti coinvolte; il project manager dovrebbe gestire l'influenza dei vari stakeholder sui requisiti per garantire un completamento con successo.
L'area è stata introdotta dal PMBOK 5ª edizione. Alcuni processi non erano nuovi ed erano già previsti dalla 4ª edizione, ma erano inclusi nell'area Communications Management. Proponendo la nuova area si è voluto rafforzare l'importanza dei processi di gestione degli stakeholder, sottolineando il coinvolgimento durante l'intera durata del progetto.
Il coinvolgimento non si deve limitare alla semplice comunicazione dello stato di avanzamento, ma deve prevedere una partecipazione attiva e costante degli stakeholder durante l'intero progetto. È la stessa richiesta che il Manifesto Agile formula come «business people and developers must work together daily throughout the project».
| PMBOK 4ª ed. (in Communications) | PMBOK 5ª ed. (area propria) |
|---|---|
| Identify Stakeholders Manage Stakeholder Expectations |
Identify Stakeholders Plan Stakeholder Management Manage Stakeholder Engagement Control Stakeholder Engagement |
| Processo | Definizione PMBOK |
|---|---|
| Identify Stakeholders | The process of identifying the people, groups, or organizations that could impact or be impacted by a decision, activity, or outcome of the project; and analyzing and documenting relevant information regarding their interests, involvement, interdependencies, influence, and potential impact on project success. |
| Plan Stakeholder Management | The process of developing appropriate management strategies to effectively engage stakeholders throughout the project life cycle, based on the analysis of their needs, interests, and potential impact on project success. |
| Manage Stakeholder Engagement | The process of communicating and working with stakeholders to meet their needs/expectations, address issues as they occur, and foster appropriate stakeholder engagement in project activities throughout the project life cycle. |
| Control Stakeholder Engagement | The process of monitoring overall project stakeholder relationships and adjusting strategies and plans for engaging stakeholders. |
È una tecnica per raccogliere e analizzare in modo sistematico informazioni quantitative e qualitative per determinare quali interessi dovrebbero essere considerati nel progetto. Identifica interessi, aspettative e influenza degli stakeholder e li mette in relazione con gli obiettivi del progetto; identifica anche le possibili interrelazioni tra stakeholder e progetto, per trarre vantaggio da potenziali coalizioni e partnership e aumentare le possibilità di successo.
Si consideri che l'influenza dei diversi stakeholder può variare durante il progetto. Una mappa degli stakeholder fatta allo scoping e mai più aggiornata è, dopo qualche mese, una mappa di un territorio che non esiste più.
L'ultimo passaggio del quadro d'insieme è la mappatura delle aree di conoscenza sui gruppi di processi: ogni area contribuisce con processi diversi in gruppi diversi, ed è questo incrocio che il PMBOK descrive processo per processo.
Un elemento alla volta: riconosci l'area di conoscenza che lo contiene.
Scoping/Initiating: sviluppa e ottiene l'approvazione di una dichiarazione generale su obiettivi e business value del progetto. Planning: identifica le attività necessarie a implementare i requisiti, stima tempo/costi/risorse e ottiene l'approvazione del piano. Launching/Executing: seleziona il personale, stabilisce le regole operative del team e lo aiuta a lavorare assieme. Monitoring & Controlling: verifica lo stato di avanzamento rispetto al piano, risponde alle richieste di modifica e risolve i problemi. Closing: assicura il soddisfacimento di tutti i requisiti, consegna i deliverable e decreta la fine formale del progetto.
Perché i process group possono essere mappati in diverse modalità, dando origine a PMLC anche articolati e complessi: è la mappatura, non il gruppo, a definire il ciclo di vita. Inoltre i process group non sono partizionati e sequenziali rispetto al tempo: processi appartenenti a gruppi diversi spesso coesistono e interagiscono durante il ciclo di vita. Infine, i processi di gestione devono essere strettamente correlati ai processi di produzione della soluzione, dall'ideazione al deployment.
Integration, Scope, Time, Cost, Quality, Human Resources, Communications, Risk e Procurement Management; la decima è Stakeholder Management, inserita a partire dalla quinta edizione del PMBOK. Alcuni dei suoi processi non erano nuovi: erano già previsti dalla quarta edizione, ma inclusi in Communications Management.
La durata (elapsed time) è il tempo di calendario; la quantità di lavoro (effort/labor) è l'impegno richiesto. Non coincidono perché il modello assume un'efficienza individuale del 75% e che le interruzioni non pianificate valgano il 33% del tempo di orologio. Conta perché la durata serve a costruire la schedula e determinare le milestone, mentre la quantità di lavoro serve a valutare i costi e assegnare le risorse: vanno stimate entrambe, con la stessa metodologia.
Quality Planning: determina gli standard rilevanti e cosa serve per soddisfarli; ha come input i fattori ambientali esterni e interni, il POS e il Project Management Plan, e produce un Quality Plan che documenta come soddisfare le politiche, le metriche di misura e un programma di miglioramento dei processi. Quality Assurance: le attività per garantire il rispetto del piano di qualità (quality audit, process analysis, tool di gestione). Quality Control: monitoraggio delle performance per stabilire la conformità agli standard e definizione delle azioni in caso di non conformità.
I Motivators sono realizzazione, riconoscimento, progressioni di carriera e crescita professionale, responsabilità, il lavoro stesso. Gli Hygiene Factors sono politiche aziendali, pratiche amministrative, condizioni di lavoro, supervisione tecnica, relazioni interpersonali, sicurezza del lavoro, salario. Nell'indagine di Couger l'ordine di priorità metteva al primo posto il lavoro stesso, seguito da opportunità di realizzazione e di progressione di carriera, con salario e benefit al quarto posto.
L'informazione deve essere trasmessa correttamente; un messaggio inviato è un messaggio ricevuto; l'informazione deve essere compresa dal destinatario; l'informazione deve essere accettata dal destinatario. Il processo passa da sender (genera l'idea, codifica il messaggio, trasmette su un canale) a receiver (decodifica, verifica il significato) e torna indietro con il feedback.
Si moltiplica la probabilità che l'evento si verifichi per l'impatto effettivo. Esempio: probabilità 1% e perdita di 50.000 euro danno 0,01 × 50.000 = 500 euro. Serve a prioritizzare i risk driver. Due conseguenze: un rischio con impatto atteso irrilevante può essere ignorato; e un evento certo non è un rischio, perché se non c'è probabilità non c'è rischio.
Categorie: Technical (adeguatezza, affidabilità, performance, disponibilità e complessità delle tecnologie), Project management (allocazione risorse, struttura di gestione inadeguata, pianificazione carente, inesperienza, indisciplina), Organizational (sostenibilità e priorità, finanziamenti inadeguati o sospesi, conflitti con altri progetti, politiche aziendali), External (requisiti legali, congiuntura, scioperi, fornitori, deliverable di team esterni). Strategie: Accept, Avoid, Contingency planning (cosa fare in futuro se accade), Mitigate (cosa fare subito per minimizzare l'impatto), Transfer (assicurazioni, conto terzi).
Lo statico valuta i rischi una sola volta, all'inizio del progetto durante il planning. Il dinamico aggiorna quella valutazione durante l'avanzamento: man mano che le attività vengono eseguite si acquisiscono nuove informazioni utilizzabili per stimare probabilità e impatto di ciascun rischio. L'approccio dinamico consente una gestione migliore del rischio.
L'RFP (Request for Proposal) è il documento inviato ai vendor potenzialmente interessati, con tutti i dettagli per capire se possono soddisfare le richieste; è preparato di solito dal Procurement Office e supervisionato dall'ufficio legale, perché può costituire la base del futuro contratto. L'RFI (Request for Information) viene prima ed è una lettera o un questionario da inviare quando non si conosce il mercato di riferimento e non si sa nemmeno a chi mandare l'RFP: serve a selezionare i vendor che potrebbero essere interessati.
No Award: nessun vendor soddisfa i requisiti minimi — bisogna ripetere la procedura dall'inizio o rinunciare. Single Award: è stato selezionato un fornitore unico. Multiple Awards: nessun fornitore poteva soddisfare tutti i requisiti, ma due o più vendor possono dividersi il lavoro e soddisfarli. La negoziazione del contratto parte poi da una delle ultime due situazioni.
È una tecnica per raccogliere e analizzare sistematicamente informazioni quantitative e qualitative per determinare quali interessi considerare nel progetto: identifica interessi, aspettative e influenza degli stakeholder, li mette in relazione con gli obiettivi e individua le interrelazioni utili a costruire coalizioni e partnership. Va aggiornata perché l'influenza dei diversi stakeholder può variare durante il progetto. Il coinvolgimento, inoltre, non si limita a comunicare lo stato di avanzamento: richiede partecipazione attiva e costante per l'intera durata.