PMTSI di Vito Madaio - Tel. 348-3974474

Cosa è la “Performing Organization”

/in , , , /da

Cosa è la “Performing Organization” più volte citata dal PMBOK Guide?

performing-organizationUna organizzazione ha sempre l’ambizione di fornire la massima prestazione, cosa non facile se non sono chiari ruoli e responsabilità di ognuno. Qualcuno ha addirittura dubbi sulla struttura alla quale si fa riferimento con “Performing Organization“.

Cerchiamo di fare un po’ di chiarezza, in base allo schema di riferimento del PMBOK Guide.

Dal glossario leggiamo letteralmente: “Performing Organization. An enterprise whose personnel are most directly involved in doing the work of the project or program. – Impresa il cui personale è maggiormente coinvolto in modo diretto nello svolgimento del lavoro del progetto o programma.”

Non c’è alcun dubbio che si fa riferimento all’organizzazione incaricata del lavoro necessario per realizzare il progetto, anche se parte del lavoro può essere svolto da altre strutture. Quindi, possiamo dedurre che “Performing Organization” e “Project Organization” sono equivalenti per la parte che si riferisce al singolo progetto. Va tenuto presente che la Performing Organization può fare molte altre cose oltre al progetto in questione.

La Performing Organization non deve essere confusa con “Projectized Organization” – una struttura organizzativa focalizzata su un singolo progetto, dove il Project Manager ha l’autorità di prendere decisioni, assegnare priorità e acquisire risorse sul progetto. Per chiarire quanto appena affermato, vale la pena scorrere il PMBOK, evidenziando i riferimenti principali alla Performing Organization.

  1. In Ruolo del Project Manager (§1.7) si afferma: “Il Project Manager è la persona incaricata dalla Performing Organization di guidare il gruppo responsabile del raggiungimento degli obiettivi del progetto. Il ruolo di un Project Manager è diverso da quello di un manager funzionale o di un manager delle unità opera Solitamente il manager funzionale si focalizza sulla supervisione gestionale di una determinata area funzionale o unità aziendale, mentre i manager delle unità operative sono responsabili di garantire che le attività aziendali siano efficienti. A seconda della struttura organizzativa, un Project Manager può riportare a un manager funzionale. In altri casi, possono esserci più Project Manager che riportano a un Portfolio Manager o a un Program Manager che è il responsabile ultimo dei progetti di portata aziendale. In questo tipo di struttura, il Project Manager lavora a stretto contatto con il Portfolio Manager o il Program Manager per raggiungere gli obiettivi del progetto e per garantire che il piano di Project Management sia in linea con il piano globale del programma. Il Project Manager lavora inoltre a stretto contatto e in collaborazione con altri ruoli quali analisti aziendali, responsabili dell’assicurazione qualità ed esperti in materia.”
  1. Nella Gestione della Qualità (§8.0) si afferma “La gestione della qualità di progetto include i processi e le attività della Performing Organization che determinano le politiche di gestione della qualità, gli obiettivi e le responsabilità in modo che il progetto soddisfi le esigenze per le quali è stato intrapreso. La gestione della qualità di progetto utilizza direttive e procedure per applicare, nell’ambito del contesto del progetto, il sistema di gestione della qualità aziendale e,a seconda dei casi, supporta le attività di continuo miglioramento dei processi intraprese per conto della Performing Organization. La gestione della qualità di progetto mira a garantire che i requisiti del progetto, inclusi quelli del prodotto, siano soddisfatti e validati.
  2. Nella Gestione delle Risorse Umane (§9.0) si afferma “Il gruppo di Project Management è un sottoinsieme del gruppo di progetto ed è responsabile delle attività di Project Management e di leadership quali l’avvio, la pianificazione, l’esecuzione, il monitoraggio, il controllo e la chiusura delle varie fasi di progetto. Questo gruppo è chiamato anche gruppo di leadership, gruppo di coordinamento o core team. Per progetti di dimensioni minori, le responsabilità di Project Management possono essere condivise dall’intero gruppo o gestite esclusivamente dal Project Manager. Lo sponsor del progetto lavora con il gruppo di Project Management, fornendo solitamente assistenza per quanto riguarda il finanziamento del progetto, il chiarimento dell’ambito, il monitoraggio dell’avanzamento e l’influenza sugli stakeholder sia nell’organizzazione richiedente che nella Performing Organization a vantaggio del progetto.
  3. Nel paragrafo 2.2.3 Acquisizione si afferma “Quando la Performing Organization non è in grado di fornire il personale necessario per completare un progetto, i servizi richiesti possono essere acquisiti da fonti esterne. Ciò può comportare l’assunzione di consulenti individuali o il subappalto di lavoro a un’altra organizzazione.”
  4. Nel paragrafo 3.2.2 Formazione si afferma “La formazione include tutte le attività studiate per migliorare le competenze dei membri del gruppo di progetto. La formazione può essere formale o informale. Tra gli esempi di metodi di formazione vi sono i corsi in aula, on-line, su computer, la formazione sul campo da parte di un altro membro del gruppo di progetto, mentoring e addestramento. Se i membri del gruppo di progetto non dispongono delle necessarie capacità tecniche o gestionali, queste possono essere sviluppate nell’ambito del lavoro del progetto. La formazione schedulata ha luogo come indicato nel piano di gestione delle risorse umane. La formazione non pianificata ha luogo a seguito dell’osservazione, conversazione e valutazione delle prestazioni del progetto durante il processo di controllo Gestire il gruppo di progetto. I costi di formazione possono essere inclusi nel budget del progetto o sostenuti dalla Performing Organization se le competenze aggiunte possono essere utili per progetti futuri. La formazione può essere erogata internamente o da formatori esterni.”
  5. Nella gestione delle acquisizioni di progetto (§12) appare “La gestione dell’approvvigionamento di progetto include i processi necessari per acquistare o acquisire i prodotti, servizi o risultati necessari all’esterno del gruppo di progetto. L’organizzazione può essere l’acquirente o il fornitore dei prodotti, servizi o risultati di un progetto. La gestione dell’approvvigionamento di progetto comprende i processi di gestione dei contratti e di controllo delle modifiche necessari per sviluppare e amministrare i contratti o gli ordini di acquisto emessi dai membri autorizzati del gruppo di progetto.

In conclusione, la Performing Organization è la struttura che sovrintende all’organizzazione del progetto del quale poi diventa responsabile un solo individuo, ossia il Project Manager.

Date le variegate forme di strutture organizzative che possono organizzare progetti, di volta in volta, bisogna individuare le figure di riferimento, in particolare lo Sponsor con quale il Project Manager deve intessere le giuste relazioni. Mentre il Project Manager è responsabile della realizzazione delle attività del progetto, lo Sponsor è responsabile del finanziamento del progetto e quindi del ritorno dell’investimento nei confronti dell’azionista della sua struttura.

Questo è un esempio delle analisi che si apprendono nei corsi di formazione TenStep, in particolare nei corsi per la certificazione PMP per project manager. Se sei intressato contattaci oppure iscriviti a PMP-Prep Online per certificarti in meno di 100 giorni.

PMP-certUna certificazione PMP è per sempre!

Come Essere un Grande Project Leader

/in /da

L’aspirazione  di ognuno di noi è diventare un fantastico leader!

E’ difficile diventare un grande leader nel breve periodo. Ma se devi gestire un gruppo di progetto per un ragionevole periodo di tempo hai la possibilità di mostrare tutta la tua qualità di leadership.

Segui queste quattro semplici regole per riuscirci:

  1. Imposta chiari obiettivi di progetto

Tutti i bravi leader si assicurano che il loro team sappia il motivo per cui stanno insieme e cosa stanno cercando di realizzare. Ciò dà al team uno scopo e rende chiaro cosa cercano di ottenere insieme. E’ moto più facile guidare un team se tutti sanno dove stanno andando. Ci dovrebbero essere pochi obiettivi (da 4 a 7) in modo che sia più facile per il team concentrarsi su quelli più importanti.

  1. Motiva singolarmente i tuoi collaboratori

Scopri cosa motiva le persone del tuo team. Per qualcuno è il salario, per altri è fare il lavoro che gli piace e per altri può essere lavorare in un grande team (il senso di appartenenza). Conoscendo i fattori motivanti di ognuno, puoi mantenere il team motivato durante tutto il progetto. Alcuni approcci, come gli esercizi di team building, possono motivare un intero gruppo. Altre attività bisogna rivolgerle al singolo membro del team.

  1. Riconosci le buone prestazioni

I grandi leader riconoscono le grandi prestazioni sull’intero team. Bisogna sempre cercare nuovi modi di riconoscere al team il comportamento corretto. I sono due modi per farlo. Il primo è quando il team raggiunge insieme un certo target. Per esempio, potresti organizzare una cena quando il team completa una fase di progetto nei tempi. Il secondo  tipo di riconoscimento  è più personale. A quei membri del team che si sono distinti con una  prestazione eccezionale, offrire un premio speciale per la buona prestazione. Il premio, non necessariamente deve essere costoso. E’ il pensiero che conta e il riconoscimento personale che la persona riceve.

  1. Continua a sviluppare la tua professionalità

I grandi leader di progetto cercano continuamente di migliorare la loro capacità di guidare il team. Oggi, ci sono tante fonti per informarsi e formarsi: corsi in persona, e-class, libri, riviste, siti web, webinar, seminari e tanto altro.

Molti grandi leader stanno costantemente in contatto con TenStep per sapere le novità sulla disciplina del project management e per farsi consigliare ogni qualvolta stanno affrontando una nuova sfida. Contattaci quando vuoi!

……………

Un modo per crescere è restare informati, utilizzando come riferimento una delle nostra metodologia. Ad esempio, puoi scaricare gratuitamente (per 14 giorni) l’intera metodologia MPMMTM, utilizzata già da migliaia di utenti in tutto il mondo. Provala scaricandola versione di prova  e se ti piace contattaci per acquistarne una o più copie. Adesso contiene anche l’intero PMBOK ® Guide in lingua inglese e un'apposita sezione sull'approccio Agile.

MPMM-AgileFree Trial

Project Manager: tutto da rifare

/in /da

L’esempio di Alessandro Magno

Alessandro-MagnoIl project management è una nobile arte praticata da secoli da tutti coloro che hanno avuto il compito di realizzare qualcosa o guidare qualcuno nel farla. Sicuramente, uno dei più grandi Project Manager, a modo suo, è stato Alessandro Magno. In pochi anni fondo ben 13 città con il suo nome, cambiando la storia di tre continenti con i suoi progetti di conquista.  Giusto per inquadrare il personaggio – nato a Pella nel 356 ac  e morto a Babilonia nel  323 ac – Allievo di Aristotele, – fu  Re di Macedonia dal 336 al 323 ac.

Alessandria

In soli 13 anni sconvolse il mondo, ma in pratica non ha fatto altro che applicare processi e tecniche appresi dal padre Filippo e dal tutore Aristotele, una scuola niente male. Però a parte la formazione alla guerra ed al comando, ci dovette mettere molto di suo per governare un esercito mai sotto le 20.000 unità, molti mercenari, tanti popoli diversi sottomessi con tutte le diversità dai greci agli indiani.

Ma Alessandro, dopo le prime esperienze, assistito dai generali del padre appena assassinato, imparò in fretta il mestiere di RE  e, molto spesso, oltre ad amministrate il potere, seppe essere anche operativo in occasione di alcuni assedi alle città da conquistare. Quale era il piano strategico di Alessandro? Con chi lo condivideva? Quali erano i suoi obiettivi? Come nascevano i suoi progetti di conquista? Quando raccoglieva i requisiti?

Non è facile rispondere, ma è facile immaginare che Alessandro Magno osservava e faceva osservare rigidamente i pochi principi di project management conosciuti. Oserei dire che Alessandro, forse, è stato il primo ideatore della filosofia Agile! Organizzava le campagne militari (sprint per gli agilisti) in funzione dell'esito di quella precedente. E ad ogni vittoria, gratificava l'esercito e, per lasciare il segno, fondava un'altra città con il suo nome:Alessandria, che poi diventava il quartier generale per la campagna successiva.

Nella sua mente coltivava il sogno di paragonarsi ad un Dio, per via delle sue origini fatte discendere da Giove e da Achille, nei 13 anni di spedizione verso l’India non ha fatto altro che aumentare questo culto legandosi alla divinità di Shiva e Dionisio incontrati alle porte dell’India. Non perdeva occasione per fare un sacrificio a tutte le divinità insieme, per affermare che lui era l’unico loro discendente e quindi l’unico con il diritto di essere RE. In sostanza, faceva continuamente  marketing del suo importante ruolo, come dovrebbe fare oggi, qualsiasi project manager.

Ecco come viene ricordato l'avvio di un progetto di conquista da parte degli storici informati: "L'avanzata in India. Alla fine della primavera del 327 l'esercito era pronto ad iniziare l'invasione dell'India. Il progetto era andato maturando da qualche tempo nella mente di Alessandro, almeno dall'estate del 328. Erano già arrivate delegazioni di governanti indiani che speravano di utilizzare l'esercito dell'invasore per espandere i loro possedimenti. … Costoro avevano tutte le ragioni per incoraggiare l'invasione del re, che peraltro non aveva bisogno di troppi incoraggiamenti."

Origini del Project Management

Nel V secolo avanti Cristo, quando l'Europa era in balia dei barbari, Ciro il Grande  ideava già il concetto di delega con definizione degli obiettivi. Ciro il Grande (558-529 a.C.) – Re di Persia –  fu uno dei primi "Sponsor di progetto" a sua insaputa,  in quanto affidava a persone di sua fiducia il governo delle terre conquistate, dividendole nelle  così dette "satrapie", governate da un "satrapo" con un ruolo molto simile a quello del project manager di oggi. Il satrapo governava l'area affidatagli in nome e per conto del Re (Sponsor), il quale in qualsiasi momento lo poteva destituire. Il compito del satrapo era amministrare la giustizia, riscuotere i tributi e arruolare militari per l'esercito del Re. La destituzione, purtroppo, non consisteva nel semplice licenziamento, ma quasi sempre nella soppressione fisica camuffata con una congiura.

L'operato del satrapo veniva controllato da sistematiche ispezioni annuali da parte di funzionari itineranti, mandati dal Re. Oggi diremmo che il satrapo riceveva una "Quality Assurance".

Però a causa della vastità dei territori affidati, della mancanza di veloci mezzi di comunicazione e dell'ambizione di alcuni rampolli nominati, spesso il satrapo diventava un despota per il popolo, abusando dei suoi poteri e trascurando gli impegni assunti verso il Re. Oggi diremmo  che il satrapo trascurava lo Stato Avanzamenti Lavori (SAL) e la gestione degli stakeholder. Spesso, il satrapo tendeva a considerarsi un vero e proprio regnante, arrivando persino a ribellarsi al potere del Re reale. Nel giro di un paio di secoli, alcune satrapie, rette per successione dinastica, degenerarono in vere e proprie ribellioni, organizzando la famosa "rivolta dei satrapi" del 360 a.C.. Successivamente, quando Alessandro Magno (intorno al 332 a.C.), in pochi anni, conquistò tutto il Medio Oriente compresa la Persia del re Dario, utilizzò la stessa tecnica dei persiani per governare le regioni sottomesse. Addirittura, in alcuni casi, affidò il governo delle aree sottomesse agli stessi satrapi del Re Dario. 

Alessandro Magno, consapevole del rischio dell'eccessivo potere nelle mani del satrapo, ridimensionò il suo ruolo, togliendogli tutti i poteri militari e  intensificando le ispezioni contabili sulla raccolta dei tributi raccolti. Oggi diremmo che Alessandro Magno istituì il "Controllo di Gestione". L'approccio di Alessandro Magno fu poi seguito anche dai Romani nel periodo di espansione dell'Impero.  Sia con Alessandro che con i Generali Romani, quando un governante assediato si arrendeva, poteva negoziare le condizioni  per continuare a governare i territori in nome del nuovo sovrano,  impegnandosi a raccogliere i tributi. Oggi diremmo che si raggiungeva un accordo "Win-Win", anche se il potere negoziale pendeva dalla parte del sovrano, il quale, per pura convenienza,  concedeva al satrapo di continuare a governare il suo territorio, purché facesse gli interessi del nuovo Re. I Romani, successivamente, affinarono ulteriormente il ruolo del "satrapo" applicando, alla lettera, il motto "divide et impera" attribuito a Filippo – padre di Alessandro Magno.

Il project management di oggi, sebbene molto più sofisticato, a livello di intelligenza umana non è niente di diverso, anzi poggia proprio sulle "Lessons Learned" ereditate dalla storia. E' tuttora in uso assegnare i compiti (gli obiettivi) in funzione dei risultati che vogliamo ottenere e quando i problemi sono complessi è preferibile suddividerli in problemi più semplici sia per poterne praticare il controllo, sia per non concedere troppo potere ad una sola persona.  Così siamo passati dalla gestione dei singoli progetti alla gestione di programmi di progetti.

Evoluzione del Ruolo di Project Manager

Tempo fa’ scrivevo che “Siamo tutti Project Manager” nel senso che ogni volta che ci viene affidato un compito, noi ci industriamo per svolgerlo al meglio, riferendo difficoltà e successi. Se incontriamo un ostacolo, chiediamo aiuto a rimuoverlo; se raggiungiamo un traguardo, annunciamo il nostro successo a chi ci aveva affidato quel compito e magari anche alla comunità per far sapere di cosa siamo capaci.

In questa Ottica, Alessandro Magno, essendo un Re assoluto, non aveva bisogno di riferire dei suoi risultati, ma aveva fortemente bisogno di fare tanta propaganda per intimorire i popoli da conquistare, per farsi ubbidire dalle popolazioni conquistate,  e per mantenere l’ordine nel suo esercito composto di pochi macedoni e tanti mercenari o  arruolati dalle nuove terre conquistate.

La gestione del team di progetto (l’esercito), il team building (la leadership) e l’assegnazione delle ricompense costituiva un lavoro impegnativo. In alcuni casi la ricompensa consisteva nel permesso di saccheggiare i villaggi conquistati.

Tornando ai giorni nostri, il Project Manager è responsabile al 100% di raggiungere gli obiettivi del progetto. Di conseguenza, non può essere considerato un ruolo operativo, ma un ruolo esclusivamente manageriale perché per raggiungere gli obiettivi di progetto ha bisogno di gestire processi e persone. Qualora  il Project Manager non avesse potere decisionale su processi e persone del suo progetto, allora sarebbe un semplice coordinatore di risorse, che è tutt’altra cosa.

Il PMBOK ® Guide dice che: “Il Project Management è l’applicazione di conoscenze, capacità, strumenti e tecniche alle attività di progetto per soddisfarne i requisiti.” Queste cose le governa il Project Manager in piena autonomia dallo Sponsor, al quale ricorre puntualmente, in caso di difficoltà e quando gli vuole riferire di un risultato. Lo Sponsor, una volta autorizzato il progetto, si aspetta i risultati dal Project Manager.

Quanti tipi di Project Manager esistono?

Qualcuno sostiene che la cultura del project management è ormai diffusa anche in Italia. Io ho i miei dubbi, viste le tante sciocchezze che si leggono ogni giorno. Molte aziende pensano di fare del project management appoggiandosi a questo o quell’esperto di turno.  Sostituito l’esperto, si sostituisce anche la metodologia. Troppo facile, ma purtroppo non è così.

Per fare seriamente del project management, non c’è bisogno di appartenere ad una associazione in nome della legge 4/2013, sarebbe preferibile consolidare una metodologia di project management riconosciuta a livello mondiale e non dall’esperto di turno. La legge 4/2013, giustamente, non parla della figura del Project Manager perché si rivolge a tutte le professioni non regolamentate. Prova ne è che a distanza di circa 3 anni, non esiste ancora una norma UNI che preveda la figura del Project Manager. Se ne parla da diversi anni, ma, in realtà ad oggi (Ottobre 2015) non è stata ancora pubblicata una norma che descriva la figura del Project Manager. Siamo tutti ansiosi di attingere a questa norma, ma al momento non c’è. In assenza di una simile norma, i nostri riferimenti restano i soliti:

  • Il PMBOK Guide del PMI – lo schema di riferimento del project management
  • Le metodologie di project management come TenStep,MPMM o Prince2.

Ricordo, a chi mi legge per la prima volta, che mentre il PMBOK Guide dice COSA FARE, le METODOLOGIE indicano COME FARLO. Chiudono il cerchio le TEMPLATE a corredo di ogni buona metodologia che rappresentano le deliverable delle attività di project management.

E’ indubbio che ognuno di noi (quasi tutti) siamo in grado di portare avanti un progetto con il nostro approccio personale. Per un’azienda seria, ciò non vale niente, anzi in alcuni casi è deleterio.

Un’azienda non ha nessuna difficoltà a nominare “project manager” chiunque  lo chieda. In fondo si tratta di un ruolo temporaneo e non di un livello funzionale. Questo è il motivo per cui troviamo tante definizioni della figura del project manager.  Inoltre, in Italia è molto diffusa la figura del Project Manager “prima donna”,  di nessuna utilità all’azienda. Forse risolve, se ci riesce, qualche problema contingente, ma non porta da nessuna parte sul lungo termine. La gestione dei progetti nelle aziende competitive deve basarsi su una metodologia di project management, personalizzata e condivisa da tutto il management. La metodologia non può essere un insieme di copia e incolla fatti dall’esperto di turno, ma deve essere basata su un progetto di stesura della metodologia oppure su una metodologia commerciale esistente.

Le metodologie basate sull’esperienza di un solo esperto sono un bumerang per l’azienda il giorno in cui l’esperto cambia casacca, cosa non improbabile. Invece, in virtù del principio del miglioramento continuo, anche una metodologia commerciale è migliorabile. I miglioramenti di una metodologia possono provenire dall’autore, ma possono essere anche frutto di considerazioni degli utenti, i project manager stessi. Con pochi ritocchi, tra personalizzazioni e miglioramenti interni, una metodologia, se proposta correttamente, si integra velocemente in un ambiente e ne diventa parte essenziale e trasparente dopo qualche ciclo.

Il management dovrà fronteggiare eventuali “resistenze al cambiamento”, ricorrendo anche a decisioni drastiche per creare il consenso e sostenere il proprio investimento. E’ in questi frangenti che l’azienda perde i Project Manager “prime donne”.

Le template iniziali, parte integrante della metodologia, dopo qualche osservazione, vengono accettate e considerate proprie dalla maggioranza degli utenti, generando l’atteso consenso.  Metodologia e template si integrano nell’ambiente e vanno a far parte della cultura condivisa, il vero patrimonio aziendale.  

Chi non è in grado di riconoscere questo merito e questo valore alle template di una metodologia, non è in grado di apprezzare il reale valore aggiunto di una metodologia di project management. Se continuiamo a sorridere quando incontriamo un prototipo di template, magari volutamente scarno, non abbiamo capito di cosa stiamo parlando

Il project management non è per tutti, ma tutti eseguiamo continuamente progetti. Potremmo farlo meglio, a costi inferiori, in tempi più brevi e con livelli di qualità concordati. Una metodologia di project management aiuta, ma non risolve tutti i problemi se non viene utilizzata nel verso giusto. Purtroppo, siamo tutti project manager, ma non tutti utilizziamo la giusta metodologia di project management, “beata ignoranza!”.

La ISO 21500

La ISO 21500 è una piccola guida al project management, la promessa del domani. Al momento è solo una promessa perché i contenuti sono scarni in quanto si limita ad enunciare una serie di processi, quasi identici allo standard del PMBOK. La ISO 21500 non aggiunge niente in materia di gestione progetti, ma in compenso ha creato un sacco di aspettative da parte degli addetti ai lavori, non certo delle aziende. Chi oggi fa riferimento alla ISO 21500, ricorre poi  al vero project management che è nel PMBOK Guide (cosa fare) e nelle metodologie di project management (come farlo).

Conclusione: tutto da rifare

Probabilmente non tutto è da rifare, ma qualcuno deve smettere di parlare di acqua calda o di aria fritta. I tempi sono maturi per costruire qualcosa di più serio sugli oltre 50 anni di letteratura sul project management. Ma, per favore, deve essere qualcosa di originale, al passo con i tempi, non una minestra riscaldata.

Il mio suggerimento è costruiamo su quello che c’è (le principali metodologie di project management sul mercato), permettendone seriamente la diffusione, senza gridare ogni giorno al miraggio (conoscenza, abilità e conoscenza), basato su cosa?

In questo senso i tempi sono maturi, se continuiamo ad investire nelle certificazioni di valore (PMP, CAPM, TSPM, PMI-PBA, PMI-ACP, Prince2, IPMA, 6Sigma, SCRUM). Tutto il resto è noia!