Che materia stai cercando?

5.1 - Project Management Parte 1

Appunti di Sistemi organizzativi sul 5.1 - Project Management Parte 1 basati su appunti personali del publisher presi alle lezioni del prof Brivio dell’università degli Studi del Politecnico di Milano - Polimi, facoltà di Ingegneria dei sistemi, Corso di laurea in ingegneria gestionale. Scarica il file in formato PDF!

Esame di Sistemi organizzativi docente Prof. O. Brivio

Anteprima

ESTRATTO DOCUMENTO

L’Organizzazione a Matrice

È la via di mezzo tra i due modelli visti prima, essa infatti ha come obiettivo quello di utilizzare in

modo efficiente le risorse (organizzazione funzionale) e di essere orientata all’output

(organizzazione a task-force). C’è un PM responsabile degli obiettivi del progetto, che lavora

“trasversalmente” ossia coordina risorse di aree differenti che vendono utilizzate sia dal PM che

dal capo aree.

I pro di questa struttura è appunto il fatto di essere orientata sia al risultato (basandosi su

meccanismi di coordinamento diretti e informali) che all’efficienza delle risorse.

Mentre i contro di questa soluzione risiedono nella difficoltà di gestione, infatti, le risorse

sottostanno a due capi e questo è spesso un elemento di conflitto in quanto vanno trovati accordi

per la divisione dei compiti delle stesse. Altro elemento è il fatto che il PM si trova ad operare in

condizioni di poco potere gerarchico e questo complica notevolmente il raggiungimento degli

obiettivi.

Ci sono tre configurazioni della struttura a matrice:

Matrice “debole”: in questo caso il PM ha poco potere ed è responsabile solamente degli

§ obiettivi del progetto, il suo ruolo consiste nel facilitare il rapporto tra aree differenti

(siamo vicini alla struttura funzionale), in questi casi il PM segue più progetti

contemporaneamente;

Matrice “forte”: in questo caso il PM ha grande responsabilità su risorse, obiettivi,

§ coordinamento e ha potere decisionale su come va gestito il progetto. In questa situazione

il PM è a capo di un solo progetto (siamo vicini al modello a task-force);

Matrice “mista” o “bilanciata”: è la via di mezzo, il PM coordina, pianifica e negozia la

§ disponibilità delle risorse con i capi funzionali; 8

Ambiti di applicazione delle strutture organizzative di progetto

Ci sono alcuni fattori contingenti che possono essere presi in considerazione tenendo presente

l’effetto dell’organizzazione esistente nell’influenzare le reali prestazioni di una struttura di

progetto:

- Rilevanza del progetto: più un progetto è importante per un’impresa (in termini monetari e

di utilizzo delle risorse) più è giustificato l’allocamento esclusivo di risorse, per questo la

struttura di progetto opportuna sarà di tipo forte;

- Criticità del progetto: altro aspetto che preferisce una struttura forte è la criticità degli

obiettivi del progetto, per esempio la fase di lancio di un prodotto è fondamentale e spesso

coincide con fiere ed eventi con controllabili e terminare il progetto prima o dopo ha effetti

differenti e quindi è giustificato l’impiego esclusivo di risorse;

- Novità del progetto: dove il grado di novità è basso e la tipologia di progetti è ripetitiva si

ricorre chiaramente ad una

struttura debole e funzionale,

nel caso opposto è giustificato

l’utilizzo di strutture forti che mi

permettono anche di sviluppare

nuove competenze per quel

caso specifico;

Fattori da considerare nella scelta di un modello organizzativo

Nello scegliere quale struttura adottare è importante considerare aspetti che possono

condizionare l’efficacia della soluzione adottata o rendere complessa la gestione, come:

- Il contributo del PM al progetto: una struttura forte da molto potere ad un PM che

dev’essere in possesso delle competenze manageriali e tecniche necessarie;

- Il contributo delle diverse funzioni aziendali al progetto: in caso di struttura debole il

potere passa nelle mani delle funzioni, è importante quindi che queste siano in grado di

gestire situazioni di progetto e che abbiano chiaro il progetto e le sue implicazioni in modo

da effettuare le scelte giuste;

- Il rilascio delle risorse al termine del progetto: l’uscita temporanea dalla propria funzione

può creare problemi al rientro (es: cambio di procedure all’interno della UO);

- I sistemi di valutazione delle performance: in casi forti o deboli la valutazione è “facile” in

quanto si sa chi è a pieno comando, e quindi responsabile, del progetto. Le complicazioni

nascono nelle soluzioni miste, in questi casi per una corretta valutazione bisogna saper

esattamente come sono state allocate le risorse attraverso sistemi di reporting (es: time-

sheet, sono fogli dove si compila quanto tempo si è dedicato al determinato progetto);

LA DEFINIZIONE DEI RUOLI NELLA GESTIONE DI PROGETTO

All’interno della struttura organizzativa sono presenti differenti ruoli con compiti diversi che

intervengono nel progetto.

RUOLI SPECIFICI DI PROGETTO (project manager e functional project leader)

Il project manager è, come già detto, il responsabile del raggiungimento degli obiettivi specifici di

progetto e deve garantire l’integrazione tra le diverse parti risolvendo i problemi che si

presentano. Il suo potere varia in base al tipo di struttura:

- Strutture deboli: è tipicamente focalizzato su pianificazione e controllo, si occupa di

concordare con le UO il loro contributo per le attività, facilitare il coordinamento e non ha

controllo delle risorse operative di cui si occupa il responsabile funzionale; 9

- Strutture forti: il PM ha un ruolo differente, egli infatti ha un controllo diretto sulle scelte di

progetto, gestisce le risorse negoziandole con i responsabili funzionali (ai quali spetta

ancora la selezione delle stesse), ha il compito di gestire la pianificazione e il controllo di

dettaglio delle attività di progetto;

Altro aspetto importantissimo è il bilanciamento tra autorità e autorevolezza.

L’autorità viene conferita formalmente al PM attraverso la posizione gerarchica, dai poteri

delegati e dal livello gerarchico della committenza (es: progetto commissionato da AD è molto

importante) e dal suo coinvolgimento sui sistemi di valutazione delle risorse.

L’autorevolezza è qualcosa più “naturale”, essa infatti dipende dalla capacità d’influenzare le

risorse, dalle sue competenze tecniche e gestionali e dal suo stile di leadership.

Chiaramente un PM con tanta autorità a poca autorevolezza si blocca e lo stesso succede

viceversa.

Una seconda figura all’interno dei ruoli specifici è quella del functional project leader, queste

figure sono utili nei casi di grandi progetti dove il PM da solo non riesce a gestire tutto, sono dei

PM operativi focalizzati sulle singole funzioni o sottoinsiemi di attività.

RUOLI DI SUPPORTO ALLE ATTIVITÀ (risk manager, contract manager)

Sono figure presenti in aziende molto orientate ai progetti e vengono racchiuse all’interno di UO di

staff. Il risk manager è colui che supporta il PM nell’identificazione e nella gestione di fattori di

rischio associati al progetto. Il contract manager si occupa più dell’aspetto contrattuale dei

progetti, quindi contratti con clienti, partner ecc. monitorando le attività al fine di rispettarli.

RUOLI NELL’ORGANIZZAZIONE PERMANENTE (responsabili di funzione e membri team di progetto)

Sono quei ruoli all’interno della struttura organizzativa che sono maggiormente coinvolti, ossia i

responsabili di funzione e i membri del team di progetto. I primi hanno il compito di gestire le

risorse e il loro ruolo è strettamente legato a quello del PM, mentre i secondi costituiscono le

risorse coinvolte temporaneamente nel progetto.

Per organizzare un progetto e allocare le responsabilità si utilizzano modelli come l’Organizational

Breakdown Structure OBS che è un organigramma di progetto nel quale vengono sintetizzate le

informazioni sulla struttura di governo, la struttura organizzativa da adottare, sulle funzioni

coinvolte e sulle risorse utilizzate. Altri modelli utilizzati sono la RAM (Responsability Assignement

Matrix) e la CA (Control Account). 10

4/05

IL CICLO DI VITA DI UN PROGETTO

Per prima cosa è bene sottolineare che ogni fase riceve alcuni input da altri fasi e genera degli

output necessari per altre fasi, spesso la complessità delle fasi fa sì che esse vengano considerate

come vere e propri processi.

Le fasi non sono sempre sequenziali, questo perché ci possono essere fasi precedenti che

necessitano di informazioni ricavabili da fasi temporalmente successive.

Quindi, la gestione di un progetto è l’insieme e l’interazione di 5 processi (o fasi). Il primo processo

è quello di initiating che può sovrapporsi a quello di planning, successivamente abbiamo i

processi di executing e controlling che sono

per natura correlati con il processo di

planning, questo perché il progetto vinee

continuamente ripianificato durante la sua

realizzazione. Alla fine, c’è il processo di

closing che permette di trasferire l’output al

cliente e di gestire la conoscenza generata

dal progetto.

INITIATING

L’output fondamentale di questa prima fase è la decisione se procedere o meno con lo

svolgimento del progetto (GO/NO GO). Le attività principali di questo processo riguardano le

analisi relative alla fattibilità (tecnica ed economica) e alle valutazioni delle opportunità

strategiche (tecnologiche e di mercato). Va sottolineato il fatto che il processo di initiating è legato

in modo particolare agli altri processi in quanto esso è alimentato dagli stessi (si consideri per

esempio la stima dei costi, la stima dei tempi, ecc.) la sovrapposizione di queste fasi dipende

dunque dalla natura dei progetti, dalle modalità di gestione e dalle interconnessioni tra fasi

logiche distinte.

Le fasi del processo sno essenzialmente 3, cioè la generazione della richiesta di progetto

(statement of work), la definizione preliminare del progetto (project charter) e l’approvazione e il

lancio del progetto.

Statement Of Work

È la prima attività formale per la nascita di un progetto, questa richiesta contiene informazioni

sulle necessità da soddisfare, sul tipo di output e sui requisiti fondamentali (in caso di lancio di un

nuovo prodotto). È importante comprendere che questo documento descrive cosa deve fare

l’output del progetto ma non il come. È di varia forma (formale o informale, es: mail) ed è

solitamente creato da un initiator. Questa figura può essere sia interna che esterna all’azienda, la

sua “esternità” è più evidente in casi di one of a kind project.

Project Charter

Il project charter non è altro che un documento più completo dello SOW che ha come obiettivo

quello di supportare il processo decisionale di selezione dei progetti all’intero dell’azienda. Un

project charter completo contiene:

- Motivazioni alla base del progetto: quindi tutti gli impatti attesi in caso di realizzazione e

in caso di NON realizzazione;

- Obiettivi specifici di progetto: questi obiettivi sono costituiti dalle specifiche del prodotto,

dal processo produttivo, dal time to market, dal costo di produzione ecc. Chiaramente la 11

definizione di questi obiettivi è influenzata dagli obiettivi e dalle strategie dell’azienda. In

questo passaggio vengono anche definiti i principali derivelable ossia ogni forma di output

(intermedio e definitivo) che passa dal progetto al cliente;

- Macro-attività e organizzazione: Definizione delle attività da svolgere per raggiungere gli

obiettivi specifici e quali risorse e UO verranno coinvolte;

- Tempi e costi: è necessario avere un’idea di massima, è utile definire un piano temporale

di raggiungimento dei traguardi (milestone plan);

- Rischi: infine il project charter dovrebbe contenere anche una presentazione di quelli che

sono gli eventuali rischi che potrebbero impattare sulle performance di progetto.

Il passaggio da statement of work a project charter è un passaggio che richiede di dettagliare e

approfondire la descrizione del progetto, per questo motivo sono coinvolte molte unità differenti

e spesso si creano (in aziende strutturate) dei team di progetto coordinati dal proposal manager

al fine di elaborare un buon lavoro.

Approvazione e Lancio del Progetto

Questa fase prende come input il project charter e fa una serie di valutazioni (economiche e

strategiche) per l’approvazione del progetto.

Per quanto riguarda le valutazioni economiche sono facile in termini di costi per tutti i tipi di

progetto mentre sono più complicate in termini di ricavi previsti per alcuni progetti (es: per un

progetto su commessa i ricavi sono prestabiliti da contratto mentre per progetti su nuovi prodotti

vanno effettuate delle stime sulle vendite).

Va detto che la valutazione economica non dice tutto di un progetto, va fatta anche una

valutazione strategica che consideri eventuali conseguenze del progetto. Sarebbe anche

opportuno fare delle considerazioni sul livello di rischio del progetto.

Infine, va fatta una riflessione sul ruolo del PM nel processo d’initiating, preso atto che l’ultima

parola di questo processo spetta al committente qual è il ruolo del PM? Esso, se presente (sì in

realtà strutturate), dev’essere assolutamente coinvolto nel processo non come coordinatore

(spetta all’initiator o al proposal) ma come risorsa di questo processo. Questo è fondamentale in

quanto il passaggio di consegne dalla fase di initiating alla fase di executing è reso in questo modo

molto più facile.

I PROCESSI DI PLANNING, EXECUTING E CONTROLLING

Il processo di planning ha due obiettivi principali: il primo è quello di fornire dati e informazioni su

tempi, costi, rischi ecc. al processo di initiating in modo che esso possa generare output. Il

secondo obiettivo è quello di massimizzare la capacità di raggiungere lo scope di progetto. Per fare

ciò il processo di planning si integra costantemente con quello di controllo.

Capita spesso che il progetto si discosti da ciò che era stato pianificato durante il processo di

planning questo fattore può essere dovuto a variabili esterne (es: ritardo di fornitori) o a possibili

errori di pianificazione (es: stime di tempi errate). È quindi evidenti che per gestire questa

situazione bisogna poter controllare il processo in modo da rendersi conto della presenza di

eventuali scostamenti, questo controllo è reso possibile solo in presenza una corretta

pianificazione, ossia attraverso l’opportuna definizione degli obiettivi specifici, delle attività da

svolgere, delle risorse, dei tempi e dei costi. 12

Il processo di planning ha come output finale la creazione di un project management plan (ossia la

creazione di un piano di progetto). Questo piano contiene tutti gli aspetti del progetto ed è

l’evoluzione del project charter, sia per quanto riguarda il livello di dettaglio che la quantità degli

aspetti considerati dall’analisi.

Il processo di controlling si nutre quindi di questo project

management plan e genera dei risultati, questi risultati

provocheranno degli aggiornamenti del piano che andranno a

rialimentare il processo di controllo.

In tutto questo l’esecuzione del processo (executing) è

estremamente connesso, esso infatti fa da “ponte” tra i due

processi di cui abbiamo parlato prima.

Decentramento decisionale e controllo per allarmi

Chiaramente, all’interno di un progetto, il lavoro va distribuito sulle risorse coinvolte (selezionate

per quantità e area di competenza necessaria). Bisogna ora vedere come queste risorse vengono

utilizzate nelle varie fasi di un progetto.

Per quanto riguarda il decentramento della pianificazione, questo aspetto è inevitabile nella

maggior parte dei casi. Questo perché spesso bisogna prendere delle decisioni specifiche e diventa

quindi impensabile che il PM possieda tutte le competenze necessarie, esso sarà piuttosto

responsabile di delineare ed integrare la progettazione di tutte le attività (effettuate dalle

rispettive aree o sotto-team di progetto) fornendo la pianificazione finale e controllandone la sua

fattibilità in termini di tempi, costi e di contenuto.

Parlando, invece, del decentramento del controllo, anche qui come prima è opportuno

suddividere i controlli tra le varie aree dedicate al progetto, questo perché solo chi realmente

svolge un’attività è in grado di fornirne lo stato di avanzamento corretto. Anche qui il PM avrà il

compito di verificare se eventuali ritardi possono impattare sull’intero progetto.

In caso di progetti grandi (grandi q.tà di dati da controllare) è opportuno introdurre un sistema di

controllo per allarmi, in questo sistema l’unità coinvolta in un’attività gestisce in autonomia il

ritardo finché questo non rischia di impattare sull’intero processo, in caso opposto viene generato

un allarme per il PM che si occuperà di valutare e gestire la situazione.

Non unicità del livello di dettaglio

Le attività di progetto vengono spesso analizzate a differenti livelli di dettaglio, questa differenza è

dovuta a:

- Esperienza dei team di progetto: quando essi sono costituiti da risorse esperte, può

capitare che non si esamini in modo dettagliato visto che esse sono in grado di controllare

e dare stime di tempi e costi precise;

- Outsourcing delle attività: se si ricorre all’outsourcing per determinate attività può non

essere indispensabile dettagliare le attività mentre è comunque utile definire scadenze

intermedie per non perdere il controllo delle attività esternalizzate;

- Orizzonte temporale di pianificazione: siamo nel caso di progetti molto lunghi, diventa

difficile (e costoso) effettuare delle stime di lungo periodo precise e dettagliate. Si utilizza

la logica della rolling wave (es: si pianifica per mesi e ogni settimana che passa pianifico

un’ulteriore settimana in modo da avere sempre un mese di gap). Si programma

dettagliatamente il lavoro da fare nell’immediato mentre si rimanda la programmazione

delle attività “lontane”. 13


PAGINE

15

PESO

1.67 MB

AUTORE

Lofilao

PUBBLICATO

5 mesi fa


DETTAGLI
Corso di laurea: Corso di laurea in ingegneria gestionale (CREMONA - MILANO)
SSD:
A.A.: 2018-2019

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher Lofilao di informazioni apprese con la frequenza delle lezioni di Sistemi organizzativi e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Politecnico di Milano - Polimi o del prof Brivio Olimpio.

Acquista con carta o conto PayPal

Scarica il file tutte le volte che vuoi

Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato

Recensioni
Ti è piaciuto questo appunto? Valutalo!

Altri appunti di Sistemi organizzativi

Appunti completi di Sistemi Organizzativi + Project Management
Appunto
Sistemi Organizzativi - Change Management
Appunto
1 Teorie Organizzative Micro
Appunto
Teorie Organizzative Macro
Appunto