Glossario dei termini di Project Management

RACI – L’acronimo RACI deriva dai termini inglesi Responsible, Accauntable, Consulted e Informed. Tipicamente si parla di Matrice RACI che è una matrice bidimensionale dove una dimensione indica le persone o i ruoli che sono coinvolti nel progetto mentre l’altra dimensione rappresenta le attività. Essa indica come una persona o ruolo si pone rispetto all’attività che nello specifico può essere:

· Responsible, la persona o il ruolo ha in carico lo svolgimento del lavoro necessario per portare a termine l’attività;

· Accauntable, la persona o il ruolo è responsabile che il lavoro venga effettuato con la dovuta qualità;

· Consulted, la persona o il ruolo possono dare un contributo che viene utilizzato per completare l’attività;

· Informed, la persona o il ruolo deve essere informato sullo stato dell’attività.

 

 

RACI-VS – La matrice RACI-VS deriva dalla matrice [RACI] di assegnazione di ruoli e responsabilità. Alle responsabilità [RACI], nel modello [RACI-VS], sono aggiunte quelle relative a:

· “Verifies”, ovvero colui che deve verificare il deliverable;

· “Sign-off”, ovvero il responsabile dell’accettazione. Spesso il ruolo di Sign-off viene a coincidere con quello dell’Accountable.

Esplicitare questi ruoli aiuta, in generale, l’organizzazione a evolvere verso un maggiore livello qualitativo e di consapevolezza. In particolare abilita la condivisione di piani che includono le attività inerenti a verifica e sign-off, che possono richiedere il coinvolgimento di [stakeholder] inizialmente non evidenti, quali enti di certificazione o qualità aziendali.

 

 

RACIO (nota anche come CAIRO) – Derivata dalla matrice [RACI], aggiunge a essa il ruolo “Out of the loop”, ovvero identifica esplicitamente le risorse che non partecipano alla realizzazione del [deliverable] analizzato. Solitamente usata all’interno di organizzazioni complesse e/o durante cambiamenti organizzativi significativi, permette di porre chiarezza sulle risorse che non sono coinvolte direttamente su un [deliverable], rafforzando invece la consapevolezza del proprio ruolo. Di solito le risorse qui indicate come “Out of the loop” sono quelle che sarebbero state coinvolte nell’organizzazione precedentemente in essere o che, per motivi di conflitto di interesse, non devono essere coinvolte in una specifica attività.

 

 

RASCI (nota anche come RASIC)– Derivata dalla matrice [RACI], aggiunge a essa il ruolo “Support”, ovvero identifica anche chi contribuirà fattivamente, cioè non solo come ruolo “Consulted”, alla realizzazione del “deliverable” di progetto. Chi ha il ruolo “Support” tipicamente opera in un team coordinato dal “Responsible”, mentre la ‘A’ in questo caso indica l’Approver.

 

 

Realismo (criterio del) – Compromesso tra il criterio del [Maximax] e del [Maximin] ottenuto attraverso il coefficiente di ottimismo α, che varrà 0 se la decisione è di tipo ottimistico, mentre varrà 1 nell’ipotesi in cui prevalga un atteggiamento pessimistico. Il criterio prevede, per ogni alternativa, la somma (payoff pesato) del massimo payoff moltiplicato per α e del minimo payoff moltiplicato per 1-α. Da ultimo viene selezionata l’alternativa che massimizza il payoff pesato.MaxPayoff α + MinPayoff (1- α)

 

 

Reclamo / Claim – Rappresenta la lamentela di un cliente a fronte di un disservizio o malfun

 

 

 

Registro – Vedere [Log].

 

 

Registro dei rischi / Risk register – Documento in cui vengono riportati e correntemente aggiornati tutti i rischi identificati del progetto e da cui può risultare, in sintesi, lo stato complessivo di rischio dello stesso. In tale registro i rischi vengono opportunamente codificati e in corrispondenza di ciascuno sono indicate le diverse caratteristiche ed ogni informazione utile alla relativa gestione (ad es. classificazione, risk owner, severità, priorità, azione/i di risposta, stato, azioni di trattamento in corso ecc.).

 

 

Registro delle questioni / Issue Log – Registro che consente di documentare le [questioni] sorte all’interno del progetto.A titolo di esempio le informazioni che dovranno essere contenute nel log possono essere:· descrizione della issue;· impatto che la issue ha sul progetto;· identità di chi l’ha rilevata;· destinatario della gestione per trovare una soluzione;· data di rilevazione e di chiusura.

 

 

Regola del pollice / Rule of thumb – Traduzione in italiano dell’espressione inglese “Rule of thumb”, è usato per indicare una regola empirica o un principio che si ritiene valido ed applicabile nella maggior parte di casi simili a quello sotto esame. È assimilabile al buon senso, o ad un parere degli esperti solitamente non documentato. Tali regole possono aiutare a prevenire errori rilevanti, essendo spesso anche contro-intuitive: ad esempio molti piloti per istinto accelerano o frenano quando entrano in un banco di nebbia, invece che decelerare lentamente, come suggerirebbe la regola del pollice.L’origine dell’espressione, per quanto dibattuta e non certa, si fa prevalentemente risalire ai mastri birrai che misuravano la temperatura del mosto introducendovi il pollice al fine di capire quando inserire il lievito per produrre la birra.

 

 

Regole di base – Nell’accezione del termine, per regole base si intendono alcuni punti di riferimento che ogni project manager dovrebbe conoscere e tener ben presente nel momento in cui inizia la gestione di un progetto. Come, ad esempio: creare un buon Piano di Progetto; gestire le aspettative; mantenere il proprio team motivato.Si considerano anche regole di base quelle norme a volte scritte e riferite alla gestione di un progetto specifico che sono fondamentali per l’avvio di una procedura o di un’azione di project management. Solitamente vengo definite dal Senior project manager.

 

 

Relazione di dipendenza / Dependency – [Relazione di precedenza] con l’ulteriore specifica:· dipendenza obbligatoria se derivante da una logica rigida (“hard logic”) inerenti alla natura del lavoro da svolgere (ad es. vincoli di natura fisica)· dipendenza discrezionale se derivante da una logica debole (“soft logic”) definita nell’ambito del progetto sulla base di best practice o di altre scelte/vincoli· dipendenza esterna se derivante da un vincolo tra attività di progetto e attività non di progetto, o più in generale da un vincolo imposto.

 

 

Relazione di precedenza / Precedence Relationship – Vincolo tra due attività utilizzato nel [metodo del diagramma di precedenza]; definisce il fatto che inizio o fine dell’[attività successore] debbono verificarsi dopo inizio o fine dell’[attività predecessore]. Può essere dei seguenti tipi:

· inizio-inizio

· inizio-fine

· fine-inizio

· fine-fine

Ad esempio un vincolo fine-inizio tra attività A (predecessore) e B (successore) significa che l’attività B può iniziare solo dopo che è terminata l’attività A.

 

 

Report sulle Prestazioni / Performance report – Documento che organizza e riepiloga le prestazioni del progetto, con riferimento ad una data o a un periodo specifico. A titolo di esempio può contenere [informazioni sullo stato di avanzamento del lavoro], analisi sulle performance stesse, calcoli earned value, ecc… sempre dal punto di vista delle prestazioni misurabili e misurate realizzate nel progetto. Vedi anche [project progress report], [status report] e [reporting dell’avanzamento].

 

 

Request for Information – Tipologia di documento relativo all'approvvigionamento ([Piano di gestione dell'approvvigionamento]) in cui è definita la richiesta di informazioni specifiche sulla fornitura di prodotti/servizi da parte dell'offerente. La RFI, se collegata a una [Richiesta di Preventivo], è simile alla [Richiesta di offerta]: tipicamente la prima si utilizza per identificare uno o più fornitori di prodotti specifici la cui fornitura/erogazione può avvenire a misura; l'ultima si utilizza qualora si preferisca affidare all'esterno la realizzazione di una soluzione complessa. NB: potrebbe non essere indicata una base d'asta, potrebbe essere richiesto di produrre una risposta o una tipologia di contratto per la formulazione del prezzo.

 

 

Request for Proposal (RFP) – Vedere [Richiesta di offerta (RFP)].

 

 

Request for Quotation (RFQ) – Vedere [Richiesta di preventivo (RFQ)].

 

 

Requirement – Vedere [Requisito].

 

 

Requirements definition – Processo di raccolta, definizione e documentazione delle esigenze di progetto sotto forma di [requisito]. I requisiti sono definiti sulla base delle esigenze rappresentate dagli stakeholder interni ed esterni al progetto, sulla base del parere degli esperti per quanto riguarda i vincoli funzionali, tecnici, ambientali e progettuali, specifici dell'[area applicativa] e in termini di priorità secondo le [priorità di progetto]. Normalmente il processo di definizione dei requisiti è iterativo o fortemente interattivo e produce come risultato finale un documento dei requisiti e una [matrice di tracciabilità dei requisiti].

 

 

Requisito / Requirement – Il requisito rappresenta un elemento di specifica del risultato di progetto o del progetto stesso. Il requisito è una caratteristica quantitativa o qualitativa che specifica un comportamento, una misura o una proprietà, che soddisfa un bisogno e che produce un valore. I requisiti possono essere classificati in termini di progetto e di prodotto:

· di Progetto: definiscono le caratteristiche di gestione del progetto e di realizzazione dei prodotti, in termini normativi, legali, di processo, di logistica, ecc;

· di Prodotto: definiscono le caratteristiche dei risultati di progetto, in termini funzionali, prestazionali, tecnici/tecnologici, ambientali, di scalabilità, di usabilità, di sicurezza, ecc.

I requisiti così definiti sono utilizzati sia in fase di pianificazione ([ambito di progetto] e [ambito di prodotto]) che in fase di accettazione ([acceptance test]).

 

 

Reserve Analysis – Vedere [Analisi della riserva]

 

 

Residual Risk – Vedere [Rischio residuo].

 

 

Resource – Vedere [Risorsa]

 

 

Resource aggregation – Risorse necessarie per completare tutte le attività programmate in un determinato periodo. L’azione è basata sulla ripartizione delle risorse effettuata nella fase precedente. I risultati sono solitamene mostrati graficamente attraverso l’uso di un istogramma. Tale aggregazione può essere fatta su base oraria, giornaliera o settimanale, a seconda della unità di tempo utilizzata per allocare le risorse. Affinché l'aggregazione di risorse risulti semplice e lineare è necessario utilizzare un grafico a barre quale strumento di pianificazione. In generale, due sono i tipi di istogrammi utilizzati. Il primo riporta in un’unica tabella di aggregazione le risorse considerate nella loro complesso. Un secondo grafico parte sarà richiesto per ciascuna unità di risorse necessarie per ogni periodo considerato.

 

 

Resource allocation – Letteralmente significa allocazione delle risorse. La terminologia è riferita all’azione relativa all’assegnazione delle risorse disponibili al progetto e alle attività di cui si compone.

 

 

Resource Breakdown Structure – Vedere [Struttura di scomposizione delle risorse].

 

 

Resource buffer – Termine utilizzato nell’ambito della metodologia del Critical Chain Project Management che sta a indicare il meccanismo informativo che genera un buon coordinamento tra le attività di progetto. In altre parole, le attività precedenti devono generare un alert rivolto alle attività successive con l’indicazione della data di completamento delle attività in corso. Le risorse coinvolte nelle attività successive, grazie alla ricezione dell’alert, si dovrebbero preparare per garantire la partenza delle loro attività subito dopo la fine di quelle precedenti (o in un altro momento concordato che può essere prima o dopo la fine delle attività precedenti). Il resource buffer indica quindi la quantità di tempo con cui l’attività successiva deve essere notificata in anticipo dalle attività precedenti al fine di garantire il suo inizio in modo che non ci siano momenti di inattività nel progetto.

 

 

Resource Calendar – Vedere [Calendario delle risorse].

 

 

Resource cumulation – Affinché la gestione di un progetto, seppur considerato nella sua parzialità abbia luogo, e incontri il successo sperato, è necessario operare un’accumulazione di risorse considerate primarie: umane e di capitale. Ciò dovrà avvenire sulla base delle quantità necessarie per realizzare le attività del progetto. Determinante a tale scopo risulta l’[analisi del reticolo] visto da ogni punto di vista in cui le decisioni di pianificazione sono guidate e condizionate da vincoli di risorse (esempio disponibilità limitata di risorse o difficoltà nel gestire eventuali variazioni del loro livello di impiego).

 

 

Resource Histogram – Vedere [Istogramma delle risorse].

 

 

Resource Leveling – Vedere [Livellamento delle risorse].

 

 

Resource smoothing – Processo simile al livellamento, che ha però lo scopo di far si che, indipendentemente dai vincoli di disponibilità delle risorse, l’utilizzo delle risorse non presenti dei picchi così da rendere il più omogeneo possibile l’utilizzo delle risorse. Questo va fatto sempre nel rispetto dei vincoli temporali del progetto e senza impattare sul cammino critico.

 

 

Responsabile del rischio / Risk owner – Chi nell’ambito di un progetto è il cosiddetto “proprietario” di uno o più specifici rischi, cioè ne risulta responsabile del relativo monitoraggio, controllo ed esecuzione delle relative azioni di [risposta ai rischi] stessi. Tale soggetto o ruolo identificato nel [project management team] può anche avvalersi di altre persone o unità incaricate di porre materialmente in essere le medesime azioni di risposta; questi ultimi possono essere definiti [risk actionee].

 

 

Responsabilità / Accountability – Essere capaci (abili) di rispondere (delle proprie azioni). Concetto cardine per l’ottenimento di ogni risultato, insieme al [ruolo] deve essere chiaramente assegnata dal project manager a ogni membro del team di progetto. A ogni data responsabilità è bene sia associato un opportuno livello di controllo, ambito di autonomia/[autorità], al fine di garantire che a essa siano associate tutte le leve necessarie al suo compimento. Al concetto di responsabilità infatti si sottende il concetto di libertà di azione.Spesso associato al concetto di responsabilità è il “commitment” ovvero l’accettazione e il massimo impegno a compiere quanto concordato da parte di chi sia stato investito di una specifica responsabilità.È bene infine sottolineare che l’italiano non distingue fra due parole inglesi diverse: “accountable” e “responsible”, spesso usate per l’assegnazione di ruoli e responsabilità (Cfr. ad esempio [RACI]). Accountable, in queste matrici, è il vero responsabile ultimo del [deliverable], mentre “responsible” è chi esegue e realizza il [deliverable]. La parola “responsible” è quindi a tutti gli effetti da considerarsi un “false friend”/falso amico fra le due lingue.

 

 

Responsibility Assignment Matrix (RAM) – Vedere [Matrice di assegnazione delle responsabilità].

 

 

Result – Si intende per risultato la conseguenza finale di una sequenza di azioni tipiche di un’attività di project management o eventi espresse qualitativamente o quantitativamente. Il risultato di una serie di azioni può essere interpretato come: vantaggio, svantaggio, guadagno, lesioni, perdite, valore numerale e via di seguito. Possibili risultati sono associati a un evento a seconda del punto di vista per esempio una distanza storica considerata rilevante. Raggiungere nessun risultato può significare che le azioni sono risultate inefficienti, inefficaci, insignificanti o difettose.

 

 

Reticolo / Network – Visualizzazione schematica delle relazioni logiche tra le attività schedulate di progetto. Deve essere sempre tracciato da sinistra verso destra per riflettere la cronologia del lavoro. In un progetto esistono due differenti tipi di reticolo:

· ADM – [Arrow Diagramming Method];

· PDM – [Precedence Diagramming Method].

 

 

Reticolo di schedulazione del progetto / Project Schedule Network Diagram – Rappresentazione grafica delle attività di progetto e delle relazioni che le legano. È buona prassi nella creazione di un reticolo non avere mai rami liberi (senza predecesori o successori), gli unici nodi che possono essere lasciati liberi sono l’inizio e la fine del progetto.

 

 

Review – Attività effettuata per riscontrare l’idoneità, l’adeguatezza e l’efficacia di qualcosa (progetto, prodotto o servizio) a conseguire gli obiettivi stabiliti. Per esempio nell’ambito della progettazione si parla di “Design Review”: processo formale attraverso il quale un gruppo di persone con competenze diverse e complementari, valuta l’adeguatezza di una progettazione (design) a fronte di requisiti richiesti e propone soluzioni, qualora si riscontrino delle discrepanze.

 

 

Rework – Vedere [Rilavorazione].

 

 

Richiesta di informazioni (RFI) / Request for information (RFI) – .In un mercato con molti fornitori di servizi, può essere utile effettuare una richiesta di informazioni (RFI) processo che anticipa la presentazione RFP [Request for proposal]. Una RFI viene progettata per raccogliere informazioni relative ad un fornitore o un vendor senza che questi si senta di impegnarsi in un progetto particolare. Sovente, il documento si concentra sulle capacità dei fornitori, la loro abilità e l’esperienza. Ciò consente all'organizzazione del cliente di pre-selezionare i fornitori di servizi che hanno le capacità necessarie per la presentazione di una proposta. Il RFI è d’aiuto nella scelta dei fornitori che riescono a soddisfare le esigenze espresse del cliente.

 

 

Richiesta di modifica / Change request – Richiesta di modifica al progetto; riguarda direttamente il [Piano di Project Management] in termini di variazione all’ambito, alla schedulazione, al budget, ecc…, oppure altra documentazione di progetto tra cui ad esempio contratti, [Statement of Work (SOW)] o anche gli [asset dei processi organizzativi] tra cui ad esempio politiche processi, procedure, ecc….

Le richieste ricadono nelle seguenti tipologie:

· [correzione di un difetto];

· [azione correttiva];

· [azione preventiva];

· aggiornamenti alla documentazione di progetto.La richiesta di modifica ha origine da una iniziativa del project manager o del team di progetto oppure da un’esigenza degli altri stakeholder; può manifestarsi nei processi di monitoraggio e controllo o direttamente in quelli di esecuzione. È gestita dal processo [eseguire il controllo integrato delle modifiche].

 

 

Richiesta di modifica approvata / Approved change request – [Richiesta di modifica] che, sottoposta al processo [eseguire il controllo integrato delle modifiche], è risultata approvata e va quindi ad aggiornare il [Piano di Project Management].

 

 

Richiesta di offerta (RFP) / Request for Proposal (RFP) – Tipologia di documento relativo all'approvvigionamento ([piano di gestione dell'approvvigionamento]) in cui sono definiti gli elementi di massima e un insieme di requisiti minimi a cui gli offerenti, nel rispetto delle indicazioni e dei requisiti minimi prescritti, possono rispondere con una proposta strutturata in termini di prodotti/servizi fondamentali e accessori. Il documento, pur variando nella struttura a seconda dell'[area applicativa], richiede ai fornitori di elaborare una proposta complessa in cui sono da definirsi le modalità di erogazione, le tecniche produttive, le tecniche utilizzate per la gestione della fornitura, le caratteristiche migliorative e il piano dei pagamenti. A titolo di esempio, l'utilizzo della RFP è indicato qualora si rilevi, a seguito dell'[Analisi Make-or-Buy], la carenza di know how specifico per la definizione dei requisiti del work package e si intenda trasferire al fornitore il compito (nonché i rischi connessi) di elaborare e proporre la soluzione ottimale.

 

 

Richiesta di preventivo (RFQ) / Request for Quotation (RFQ) – Tipologia di documento relativo all'approvvigionamento ([Piano di gestione dell'approvvigionamento]) in cui è definito l'insieme di [requisiti], al quale il fornitore risponde tipicamente con un'offerta economica e un eventuale (se previsto dal RFQ) allegato tecnico. Il ricorso al RFQ occorre solitamente per forniture o servizi di cui si detiene il know-how e se ne conoscono nel dettaglio le caratteristiche.

 

 

Riconoscimenti e premi – I riconoscimenti e i premi ai membri del gruppo di progetto costituiscono la legittimazione dei comportamenti ritenuti meritevoli e dei risultati conseguiti. Il processo prevede la pianificazione dei riconoscimenti, dei momenti di valutazione e delle relative modalità di erogazione all’interno del piano di progetto. I riconoscimenti e i premi devono essere attribuiti al gruppo e non alle singole individualità poichè, quest’ultimo, sarebbe un fattore di disaggregazione, conseguente ad una tecnica di tipo “win-lose”. Per ottenere il successo del progetto, l’unico strumento valido è quello che vede premiato tutto il gruppo (“win-win”), indipendente dalle performance individuali.

 

 

Ridurre il rischio / Risk reduction – Strategia di [risposta ai rischi], in caso di minaccia, in modo da ridurre la probabilità che un evento si verifichi e/o ridurre l’impatto dell’evento, ove questo si verifichi.

 

 

Rilascio delle risorse – All’interno del piano delle risorse umane, il rilascio delle risorse è la pratica secondo cui le risorse vengono restituite alle organizzazioni di provenienza o allocate su altri progetti.Il rilascio delle risorse può avvenire in ogni fase di progetto, in funzione dei risultati raggiunti, da raggiungere e delle competenze necessarie per il prosieguo del progetto.Una pianificazione corretta e concertata, sia a livello aziendale che progettuale, del rilascio delle risorse permette di minimizzare i costi derivanti da un loro potenziale non utilizzo a cavallo fra più progetti, garantendo peraltro il mantenimento del focus e del morale delle risorse medesime, morale impattato negativamente dai periodi di non attività.Include la condivisione del feedback sulle performance della risorsa.

 

 

Rilavorazione / Rework – Tipicamente collegata alla [correzione di un difetto], implica la necessità di lavorare di nuovo ad un [deliverable] che, stante il lavoro già eseguito, doveva essere già completato e approvato. La rilavorazione può anche essere pianificata e non subita, nel qual caso non si parla di correzione di difetti. Un esempio è quando una tecnologia non sia compiutamente nota e si decida di effettuare un prototipo per testarne le potenzialità, ben consapevoli che tale lavoro andrà del tutto o in parte rifatto. Inoltre, per evitare la rilavorazione è utile includere nel team, ove possibile, chi dovrà accettare e/o usare il prodotto del progetto, al fine di identificare già nelle prime fasi gli eventuali errori presenti nelle specifiche realizzate.Infine, la rilavorazione è spesso un effetto collaterale del [fast tracking], ove la lavorazione in parallelo di più attività inizialmente raccomandate come da eseguirsi in sequenza comporta un numero di difetti tendenzialmente più elevato, minando così almeno in parte i vantaggi che si volevano ottenere con tale iniziativa.

 

 

Rischedulazione – Consiste nella riesecuzione del processo di [schedulazione] nel corso del progetto per rivedere, al variare delle condizioni del progetto, le [data d’inizio schedulata (SS)] e la [data di fine schedulata (SF)] delle attività o la data di una [milestone]. Può condurre a una nuova [Baseline della schedulazione].

 

 

Rischio / Risk – Qualsiasi evento o condizione presumibile che può realizzarsi in futuro e può essere causa di incertezza sul conseguimento di uno o più obiettivi del progetto (in termini di tempi, costi, qualità, benefici) e quindi può variarne i valori (deterministici) per il conseguimento del relativo successo, ma anche produrre ulteriori e potenziali vantaggi. Al rischio si associano pertanto una causa, che attiva o innesca il verificarsi di un evento che infine produce un effetto o impatto sul progetto. Nel caso l’impatto sia negativo, il rischio si definisce più propriamente una [minaccia], al contrario, se l’impatto è positivo, si definisce una [opportunità]. Nel caso ad esempio si abbia un cantiere di costruzione in riva ad un fiume, una pioggia torrenziale (causa), può determinare l’esondazione del fiume (evento) e quindi avere un certo impatto (incremento dei tempi e dei costi) sugli obiettivi del progetto. Come si vede, al rischio può associarsi di norma una probabilità (P) di accadimento e un valore di effetto di danno (D) o beneficio (B) a seconda che l’impatto (I) sia negativo o positivo; secondo tale modello può porsi ad es. l’espressione del danno (D = P x I) quale combinazione o prodotto della probabilità dell’evento per l’impatto. In realtà sia l’evento che l’impatto possono essere funzioni stocastiche, trattabili con opportuni modelli. Un rischio non dovrebbe confondersi con un problema o questione che risultino già manifestati, cioè [issue], sebbene possano esistere relazioni fra i due concetti. La disciplina della [gestione del rischio] viene riconosciuta come un’[area di conoscenza] del project management, con relativi processi, strumenti e tecniche di analisi, risposta ai rischi ecc. La determinazione dei requisiti di successo di un progetto non dovrebbe pertanto fare a meno di un idoneo utilizzo dei principi e delle best practice inerenti la gestione dei relativi rischi.

 

 

Rischio collaterale / Secondary risk – [Rischio] indotto e causato da determinate azioni di [risposta ai rischi] già previste per altri tipi di rischio.

 

 

Rischio residuo / Residual risk – Parte di [rischio] rimanente, che si considera ad es. accettabile, dopo che siano poste in essere le relative azioni di [risposta al rischio]. Si definisce anche inerente (inherent) il livello di rischio originale.

 

 

Rischio secondario – Vedere [Rischio collaterale].

 

 

Risk – Vedere [Rischio].Risk acceptance – Vedere [Accettare il rischio].

 

 

Risk actionee – Soggetto incaricato dal [risk owner] di mettere in pratica una [risposta al rischio].

 

 

Risk analysis – Vedere [Analisi dei rischi].

 

 

Risk appetite – Vedere [Propensione al rischio].

 

 

Risk attitude – Vedere [Attitudine al rischio].

 

 

Risk aversion – Vedere [Avversione al rischio].

 

 

Risk avoidance – Vedere [Evitare il rischio].

 

 

Risk Breakdown Structure (RBS) – Vedere [Struttura di scomposizione dei rischi].

 

 

Risk budget – Vedere [Budget di rischio].

 

 

Risk category – Vedere [Categoria di rischio].

 

 

Risk criteria – Vedere [Criteri di rischio].

 

 

Risk evaluation – Vedere [Valutazione del rischio].

 

 

Risk identification – Vedere [Identificazione dei rischi].

 

 

Risk management – Vedere [Gestione del rischio].

 

 

Risk management framework – Quadro di riferimento della gestione del rischio vedere [politica di gestione del rischio].

 

 

Risk management plan – Vedere [Pianificare la gestione dei rischi].

 

 

Risk management policy – Vedere [Politica di gestione del rischio].

 

 

Risk management process – Processo di [gestione del rischio].

 

 

Risk monitoring and control – Vedere [Controllare e monitorare i rischi].

 

 

Risk owner – Vedere [Responsabile del rischio].

 

 

Risk priority – Vedere [Priorità del rischio].

 

 

Risk profile – Vedere [Profilo di rischio].

 

 

Risk quantification – Attività di [analisi del rischio], avente l’obiettivo della sua valutazione quantitativa, in termini di valori numerici, riconducibili a variazioni degli obiettivi e parametri di progetto, quali tempi, costi nonché differenze rispetto ai requisiti originali di prestazioni e qualità, o più generalmente traducibili in un equivalente impatto di valore economico per il progetto.

 

 

Risk reduction – Vedere [Ridurre il rischio].

 

 

Risk register – Vedere [Registro dei rischi].

 

 

Risk response – Vedere [Risposta ai rischi].

 

 

Risk response planning – Vedere [Pianificare le risposte ai rischi].

 

 

Risk severity – Vedere [Severità del rischio].

 

 

Risk source – Vedere [Sorgente di rischio].

 

 

Risk tolerance – Vedere [Tolleranza al rischio].

 

 

Risk transference – Vedere [Trasferire il rischio].

 

 

Risk treatment – Vedere [Trattamento del rischio].

 

 

Riserva / Reserve – Vedere [Riserva per contingency] e [Management reserve]

 

 

Riserva per contingency / Contingency Reserve – Quantità di risorse (tempi e/o costi) prevista nel piano di progetto a cui ricorrere nel caso di eventi identificati che impattano negativamente sul progetto (rischi). È definita in quantità adeguata a ridurre, a un livello accettabile, il rischio complessivo del progetto.

 

 

Risorsa / Resource – Persona, equipaggiamento, impianto, o qualsiasi altra cosa necessaria al compimento di una attività di progetto. Due dimensioni che caratterizzano una risorsa sono:· disponibilità; · costo. Generalmente risulta variabile in relazione al grado di specializzazione della risorsa. Nel caso di risorse umane ad esempio può variare a seconda del livello di esperienza.

 

 

Risposta ai rischi / Risk response – Azione pianificata che deve essere realizzata in previsione di determinati rischi. Le strategie di risposta ai rischi sono diverse, in relazione al tipo di rischio (minaccia, opportunità). Nel caso di rischi a impatto negativo (minaccia) si definiscono le seguenti possibili strategie o modi risposta: [evitare], [ridurre], [trasferire], [condividere], [accettare il rischio]. Nel caso di rischi ad impatto positivo (opportunità) si definiscono le seguenti possibili risposte: [sfruttare], [incrementare], [condividere], [rifiutare]. Per uno stesso rischio, si possono adottare anche più tipi di risposte complementari.

 

 

Risultato / Result – Ciò che produce il progetto o costituisce, in senso lato, il deliverable finale di quest’ultimo. Anche sinonimo di prodotto o nuovo servizio realizzato dal progetto. In senso stretto per significare prodotti non materiali, come risultati di studi, ricerche e simili.

 

 

Ritardo – Vedere [Lag].

 

 

Rolling Wave Planning – Vedere [Pianificazione a finestra mobile].

 

 

Root Cause Analysis (RCA) – Vedere [Anali delle cause originarie].

 

 

Rule of Seven – La regola del sette consiste nell’analizzare la frequenza di uscita dai limiti di accettabilità dei valori in un Control Chart (relativo alla gestione della qualità nel progetto). In alcuni casi è possibile che il processo analizzato sia considerato fuori controllo anche quando, pur rimanendo nei limiti, per un certo numero di misurazioni consecutive, 7 nel caso della regola del sette, il risultato del processo è sempre sopra o sempre sotto la media. Se questo accade si può concludere che c’è un’anomalia ed è necessario indagare sulle cause.

 

 

Rule of thumb – Vedere [Regola del pollice].

 

 

Run Chart – Rappresentazione di osservazioni statistiche riguardanti le prestazioni di un processo che tiene conto della variabile tempo. Spesso è utile osservare come le prestazioni dei processi siano in relazione al momento in cui sono state prodotte oppure come sono in relazione a quelle che le precedono e che le seguono. Ciò aiuta a capire meglio come il processo sta andando e a fare previsioni sull’andamento futuro. Gli istogrammi e le distribuzioni di frequenza, infatti, mostrano le caratteristiche di un certo campione di misure riguardanti un processo ma non possono rivelare eventuali tendenze del processo stesso. Per evidenziare queste situazioni è necessario considerare i dati in ordine temporale. Ordinando i dati in un Run Chart è possibile identificare eventi e tendenze correlate al momento specifico o all’ordine in cui essi occorrono. Tutto ciò è fondamentale nella ricerca e nella determinazione di cause speciali che possono aggiunge variabilità o degradare le prestazioni. È molto facile realizzare un Run Chart con i software disponibili, es. Microsoft Excel o Minitab. Il Run Chart insieme al Control Chart è lo strumento più frequentemente utilizzato nei progetti Six Sigma ed, in genere, negli studi finalizzati al miglioramento della qualità.