Team Members’ Profile Game

Source: Wikipedia

• Let everyone facing uncertainty
• Putting each one in someone other’s shoes.
  Actually, you are called to understand, feel, make it yours and finally explain, something that someone else thinks and feels.
• Communicate face-to-face with another attendee (team member)
• Practice the art of listening

The Agile Team: a tribe or a theatral troupe?

http://broadwayhour.blogspot.com

Belonging to a theatral troupe, actors work for a long period each one near the other, they are invited, sometimes obliged by the situations, to find the most effective working behaviors, sinergies and approaches in order to let the show hits the ground.
Any actor should have a talent, have studied and practiced a lot, know very well her part in the show. But this is not enough because she is called to adapt, adjust and tailor his artistic behaviour to the existing boundaries: the other actors with their parts, behaviors, skills and approaches.
Furthermore, the actors must limit theirselves and their behaviors within spaces (the stage, the scenes), timings (acts, show).
Finally, they use as well iterations when make the rehearsals.

http://humansarefree.com/2011/06/ten-commandments-of-native-american.html

Members that belong to a tribe, accept to share not only the usual activities such as hunting, providing for the maintenance of the tribe or, furthermore, fighting. They want to share also personal experiences, spaces, feelings, emotions, accepting rules and participating in rituals and ceremonies.

 

Hence, an agile team member, like an actor, should know the “theory” and should have practiced a lot. Every activity he does is limited in terms of time (iterations), space (the workplace). He should be able to communicate well enough to collaborate with the teammates and be effective working in a group. He will take advantage of the feedback coming from the iterations and discovering and learning form the experience.

An agile team member, like a member of a tribe, should accept and follows some rules, to find the right balance between his expectations and the ones of the group. He should trust the other members at least until his trust is betrayed and in my experience this does not happen too frequently in an agile team.

Actually the parallelism with rugby is somehow perfect. Scrum in rugby, is the way the members as a team operate to conquer the ball against the counterparts.

L’importanza del team

Se vuoi arrivare primo, corri da solo.
Se vuoi andare lontano, cammina insieme agli altri.
(proverbio del Kenya)

L’importanza del gruppo è risaputa e assodata.
E’ vero, il singolo è agile e risponde velocemente ai cambi di scenario, ma la fragilità dovuta a risorse limitate gli precludono molte delle strade percorribili.

La forza del gruppo deriva dal fatto che questo, nel suo complesso, ha risorse e conoscenze maggiori e, in teoria, nessun obiettivo gli è precluso.

La minore agilità potrebbe però pesare in situazioni che richiedono forte dinamicità.

Il team agile

La teoria agile ci insegna che se un team, comunque contenuto nei numeri, ha le caratteristiche che seguono, riesce ugualmente a fare fronte a situazioni di forti cambiamenti e flessibilità.

Caratteristiche principali di un team agile:

• Orientamento verso l’effettivo valore di business del cliente
• Competenze tecniche professionali elevate dei singoli
• Dimensione ridotta del team
• Auto-disciplina nella risoluzioni di conflitti
• Personalità dei membri orientata alla collaborazione
• Buone capacità di adattamento
• Disponibilità e apertura dei singoli, all’apprendimento

Un buon leader, quindi, deve essere in grado di scegliere le persone giuste e, dal mio punto di vista,  iniziarle alla disciplina agile, creando continui stimoli volti alla comunicazione e condivisione degli obiettivi.

In questo modo sarà per lui possibile puntare a mete difficilmente raggiungibili come singolo, ma più facilmente avvicinabili come gruppo.

Comunicare le responsabilità dei singoli

Altro fattore fondamentale nella gestione del team è la comunicazione.

Questa deve essere immediata, diretta (face-to-face), chiara, semplice (vedi post precedente ‘Comunicazione Agile’).

E’ necessario che ogni membro del team conosca in ogni istante le attività a lui assegnate e le relative responsabilità.

Per ottenere risultati certi è bene fare uso di strumenti di assegnazione delle responsabilità come i seguenti.

Diagrammi gerarchici:

• WBS: identificando il responsabile di ogni WorkPackage della WBS
• OBS: struttura gerarchica organizzata per funzioni, dipartimenti e persone che saranno coinvolte nel progetto
• RBS: struttura gerarchica organizzata per tipologia di risorsa, utile anche per tracciare i costi.

Diagrammi a matrice:

• RAM : usata per illustrare le connessioni tra il lavoro necessario e i membri del Team. Può essere vista come incrocio della WBS e della OBS.
• RACI (vedi post ‘Commitment e responsabilità’): particolare formato di RAM (Responsible, Accountable, Consult and Inform) che mostra anche il grado di  coinvolgimento ai vari livelli.

La delega

Il project manager ha un importante altro strumento per ottenere responsabilità e commitment dai membri del team e che, contemporaneamente, gli permette di “guadagnare” tempo sul progetto: la delega.

La delega è definita come il decentramento temporale di responsabilità senza modificare il ruolo del collaboratore perché è limitata nei contenuti e nel tempo.

Delegare significa quindi assegnare compiti e relative responsabilità ad altre persone, attribuendo loro gli strumenti di cui hanno bisogno per eseguirli, esigendo che rispondano dei risultati conseguiti.

Il processo di delega dovrebbe quindi tenere conto di:

• chi assegna la delega e chi la riceve
• a cosa è circoscritta la delega (contesto)
• quale responsabilità comprende la delega (raggiungimento obiettivi)
• quali gli strumenti forniti al delegato
• come misurare il risultato della delega

Crescita del team

Una volta responsabilizzato e allineato il team, è necessario poi procedere a svilupparne le competenze, sia in termini di technicalities sia di soft skills.

Questo è possibile dedicando l’opportuna attenzione alle seguenti tematiche:

• Fomazione: tutte le attività volte a migliorare le competenze del team.
• Team building: attività volte a migliorare la coesione tra i membri del team.
• Ground rules: stabiliscono regole chiare (ricordate la KISS rule?) per quanto riguarda l’approccio lavorativo dei  membri. Riducono conflitti e incomprensioni.
• Co-location: collocazione fisica dei membri del team nello stesso luogo per migliorare il lavoro di gruppo e favorire la comunicazione e la libera circolazione dell’informazione.
• Riconoscimenti: favorire i premi di tipo win-win (vince il gruppo) rispetto ai win-lose (vince uno e perdono gli altri). Devono essere chiari, espliciti e raggiungibili.

Mettendo in atto quanto sopra, si otterranno principalmente tre grossi vantaggi: miglioramento delle competenze dei singoli, aumento dell’efficacia complessiva del gruppo e sensibile diminuzione del turn-around tra i membri.

E secondo voi? Quanto è importante un team in un progetto?

Management’s challenges

Ehi tu manager, accetti la sfida?

Nel corso che ho tenuto qualche settimana fà è nato un interessante scambio di opinioni relativamente alla crescita dei collaboratori.
Quella discussione, affrontata quando abbiamo parlato del processo “Develop Project Team” del gruppo “Project Human Resource Management”, ci ha poi portato a traslare il concetto di crescita anche su noi stessi (crescita personale) e, ancora più in là sull’azienda.

Siamo partiti affermando quanto fosse importante permettere e agevolare la crescita dei membri del team, cosa possibile attraverso diversi mezzi che ho in parte già affrontato nel precedente post Develop the Team.

Essere in grado di fornire sfide e stimoli continui in azienda, è una delle chiavi che permettono alla stessa di tenere ben ancorate le persone che hanno vero talento. Queste infatti aspettano, pretendono e accettano la sfida.

Dall’altra parte aiuta anche l’azienda a “scremare” in maniera piuttosto naturale, perdendole, quelle che invece non sono in grado di tenere il passo.

Quindi, credo si possa affermare che la crescita continua dei collaboratori è possibile solo se questa passa attraverso una continua crescita personale (noi stessi) e/o dell’azienda.

Nel lungo termine, infatti, non sarò in grado di fornire stimoli durevoli di crescita, se io o l’azienda nella quale opero, non stabiliranno anch’essi questo trend evolutivo.

Questa affermazione investe qualsiasi manager, di una responsabilità importantissima.

Siamo infatti noi i primi a dover accettare la sfida come vera “filosofia di vita lavorativa”, mettendoci in gioco giornalmente e ampliando con persistenza e perseveranza i nostri orizzonti di conoscenza: imparare dall’esperienza (aspetto pratico) e studiando sui libri (aspetto teorico), coscienti del fatto che l’uno non può esistere senza l’altro.

Accettando la sfida lascio aperta la porta della novità, della non-conoscenza, del cambiamento, tutti aspetti onnipresenti in ogni progetto che per semplicità ci hanno insegnato a chiamare “change request“.

Questa caratteristica, ahimé, ci espone sempre al vento e ci vede sempre impegnati a scalare l’ennesima rampa di qualche learning curve…e questo è il lato “negativo”, che però con un pò di talento, passione e “allenamento” possiamo affrontare serenamente.

Non essendo tra la’ltro questa, una peculiarità comune a tutte le persone, ci pone in una condizione di netto vantaggio rispetto agli altri: che siano essi collaboratori, colleghi o competitor.

Questo ci permette infatti di fornire nuovi stimoli, confronti, “competizioni” su cui tutti, noi per primi, possiamo misurarci e crescere.

Cosa fare però, se dall’altra parte, azienda, collaboratori, colleghi o competitor non ci seguono lungo questa rampa?

Per i competitor è meglio, non ci raggiungeranno mai.

Per gli altri è innanzitutto necessario chiedersi se quanto stiamo chiedendo/proponendo in termini di impegno è  veramente troppo sfidante/impegantivo.
E qualora così non fosse?

La vita è un viaggio e durante il viaggio troveremo altri compagni disposti a fare un pezzo di strada insieme a noi.

L’importante è non trovarsi, ad un certo punto del viaggio, completamente da soli.

Develop the team

Tra le diverse attività di project management ne troviamo alcune molto interessanti nel campo delle risorse umane, legate allo sviluppo delle competenze del team. Un bravo project manager deve saper identificare le caratteristiche dei membri del team e procedere nel rinforzarle e svilupparle, sostenendo, motivando e guidando le singole persone.

In materia di risorse umane il PMBOK espone e indirizza diverse teorie che esplorano i meccanismi motivazionali degli essere umani.

Alcune sono piuttosto interessanti ciaiutano a capirne i fenomeni antropologici, sociali e comportamentali. Di seguito ne riporto solo alcune, quelle di maggior rilievo che hanno fatto la storia della materia:

• The hierarchy of needs – Maslow
• Theory of needs – McClelland
• Theory x and y – McGregor
• Expectancy theory – Vroom
• Factor theory - Herzberg

Senza volersi perdere in troppa “accademia”, ci sono alcuni accorgimenti che personalmente ho tratto sia dalla disciplina cosi come viene descritta dal PMBOK, sia dalla teoria agile che mi ha portato a cercare di definire cosa sia un project team efficace ed efficiente.

Partiamo prima con il definire cosa intendiamo per “project team efficace“:

• Dimostrare appartenenza e self-development
• Farsi promotori di azioni innovative e creative
• Comunicare in modo efficace
• Emersione dei problemi
• Essere propensi alla risoluzione dei conflitti
• Essere orientati ai risultati
• Essere aperti al cambiamento
• Essere propositivi e positivi

Se mi venisse chiesto di prioritizzare la lista sopra non ne sarei capace: tutti i punti sono equidistanti in termini di importanza.

Con la frase “project team efficiente” invece consideriamo quanto segue:

• Orientamento verso il valore atteso dal cliente
• Competenza individuale nel campo d’azione
• Dimensione ridotta del team
• Auto-disciplina del team
• Personalità orientata alla collaborazione
• Buone capacità di adattamento
• Disponibilità e apertura all’apprendimento

Tutto quanto sopra è possibile solo lavorando sull’ambiente e creando le condizioni ideali che facilitino il lavoro di gruppo, la semplicità nelle comunicazioni, senza però dimenticare di rilasciare continue motivazioni ai membri fornendo sfide e opportunità di crescita.

Opportunità di crescita personale che possono essere anche fornite attraverso i nostri feedback frequenti, sui comportamenti e le performance, siano essi positivi o negativi da trattare ovviamente con il corretto stile comunicativo.

Crescita professionale che deve essere stimolata attraverso momenti dedicati alla formazione, anche interna.

Una formula che funziona piuttosto bene è di incaricare della formazione direttamente alcuni membri più esperti: questo produce anche effetti positivi di team building e aumenta la coesione tra i membri.

Performance eccellenti possono essere sviluppate grazie e modalità aperte e efficienti di comunicazione (vedi post precedente), sviluppando la fiducia nel team, gestendo i conflitti in maniera costruttiva e incoraggiando alla collaborazione e verso un approccio di problem solving.

Quanto sopra esposto non sarebbe, a mio avviso, possibile prescindendo da un rapporto personale, quasi dedicato, con ognuno dei membri del team. Direi un’attenzione giornaliera dedicata e quasi personalizzata, fatta di incontri e analisi delle performance dei singoli.

Qualche tempo fa parlavo di questi temi, con un imprenditore nel campo dell’editoria a capo di numerose testate di quotidiani locali. Mi raccontava di quanto ritenesse importante il rapporto continuo e personalizzato con i propri dipendenti.

Paragonava l’attenzione ai suoi dipendenti, a quella che un buon giardiniere ha per il suo giardino. Lavoro paziente a cui dedicarsi giornalmente, regolandone le siepi (fornire regole, modalità e approcci lavorativi), annaffiandone e concimandone piante e fiori (fornire stimoli, motivazione e possibilità di crescita) , estirpandone le erbacce dal prato (gestire i conflitti).

Lavoro, questo, che se fatto giornalmente, o comunque con buona frequenza, permette ai conflitti di non proliferare e al project manger di poter monitorare costantemente lo stato d’animo delle singole persone, aiutandolo a  nutrire e mantenere sempre acceso l’interesse e la passione per il progetto.

Beh? Cosa aspettate allora?

Forza: guanti, pompa dell’acqua, cesoie, fertilizzante e…….via in giardino!

Commitment e responsabilità

Nel post corrente parleremo di due temi sui quali si arenano parecchi progetti e sono la responsabilità e l’impegno rispetto a qualisiasi attività di progetto.

Il tema della responsabilità sui task di progetto viene spesso sottovalutato.

Quando si pensa al termine attività di progetto si crede che queste siano delle occupazioni a carico del solo project team, mentre il concetto di task di progetto deve essere espanso  a tutte quelle attività di esecuzione, certo, ma anche di recupero delle informazioni, risoluzione di problemi o punti aperti, attività di networking tra gli stakeholder o di promozione del progetto stesso.

Insomma, qualsiasi azione che porti ad un avanzamento incessante del progetto verso la meta.

L’esperienza mi insegna che nella maggior parte dei casi le attività di esecuzione dal team sono quelle con una effettiva alta probabilità di esecuzione nei tempi prestabiliti.

Al contrario, le altre attività spesso in carico agli altri stakeholders, sono sistematicamente sottovalutate. Peggio ancora, vengono ripetutatemente istanziate e reiterate nei meeting che si susseguno durante il ciclo di vita del progetto, annotate come open points nelle relative meeting minutes e poi regolarmente disattese.

Affianco al concetto di responsabilità di un task, troviamo il concetto di commitment.

Ho cercato la traduzione esatta del termine in diversi dizionari e ho trovato le seguenti traduzioni: impegno, dedizione, promessa, affidamento, coinvolgimento; tutti hanno molto a che fare con la parola fiducia.

Prendersi in carico qualcosa e permettere agli altri interlocutori di affidarsi a noi. Un vero e proprio vincolo tra le persone in cui ci si impegna a portare a termine un’attività.

Il commitment ha molto a che fare quindi con la sfera “emozionale” legata anche all’entusiamo che si viene a creare all’interno degli stakeholders di progetto nel portarlo a termine; entusiasmo messo a rischio quando il progetto incontra i primi ostacoli che l fanno ritardare o bloccare.

Le figure di project manager e sponsor in questi casi sono vitali e importantissime.

Il primo ha il dovere di monitorare constantemente lo svolgimento delle attività, la raccolta delle informazioni e il clima che caratterizza il progetto e le persone coinvolte.

Deve rivitalizzare l’interesse quando è in calo, rivedere le assegnazioni, richiedere solleciti feedback, porre le persone incaricate di fronte alle responsabilità di eventuali ritardi sulle loro attività.

Dall’altra parte, proprio per non eccedere in facili entusiasmi, deve cercare di regolamentare l’eccesso di entusiasmo facendo rimanere molto focalizzate le persone sulle loro attività, rimandando qualsiasi festeggiamento o entusiamo al momento dell’effettivo raggiungimento del singolo obiettivo.

Lo sponsor è vitale nell’alimentare continuamente l’interesse, che calerà di sicuo nei mesi a venire, nei confronti del management e degli utenti aziendali chiave coinvolti.

Parallelamente ad un lavoro incessante di comunicazione, per questi scopi viene i aiuto la RACI matrix.

Esistono altri due sinonimi RAM (Responsibility Assignment Matrix) o LRC (Linear Responsibility Chart) che fondamentalmente riconducono allo stesso strumento.

RACI Matrix. Fonte PMBOK 3rd Edition

• Responsible, indica a chi è in carico il task per la sua esecuzione; è la persona che è responsabile del suo completamento
• Accountable, termine che si sovrappone al precedente perchè indica sempre una responsabilità ma questa è sicuramente più forte della precedente. Potremmo riassumerla con questo esempio: un task è stato delegato da una persona ad un’altra. Chi ha preso la delega del task è il responsabile e chi l’ha fornita è in ultima analisi il vero e ultimo responsabile (accountable). Il project manager, per intenderci,  è l’unico vero accountable del progetto; il successo o il fallimento dello stesso ricadrà, in ultima analisi, sulle sue spalle
• Consult, la persona indicata da questo attributo deve essere assolutamente consultata durante l’attivazione, l’esecuzione e la fine del task in oggetto
• Inform, vincolo molto più leggero rispetto al precedente. Indica che deve avvenire un’azione di inormazione verso la persona indicata in quel task

 Spesso quando si ha a che fare con questi strumenti si effettua l’errore, io in prima linea, di sottovalutarne la forza: tutto sommato è solo una matrice che dice chi deve fare che cosa!

Invece la formalizzazione delle decisioni prese in termini di responsabilità e commitment e la sua ufficializzazione attraverso tali strumenti e un vincolo forte di fronte a tutti gli stakeholders di progetto.

Ricordate? Ha molto a che fare con la fiducia!

E, in una aggregato sociale o comunità, la comunità di progetto appunto, la fiducia è uno dei valori più importanti.

Gestione multi-progetto

Le aziende medio piccole, come per esempio la maggior parte delle software house, si trovano spessissimo a dover gestire l’esecuzione di più progetti contemporaneamente.

Tali progetti, nella maggioranza dei casi, richiedono l’utilizzo di differenti tipologie di risorse: sviluppatore junior, sviluppatore senior, software architect o specialist, project manager.

Tali progetti, inoltre, possono avere differenti gradi di difficoltà, redditività e rischi:

• Categoria A: semplici repliche o revisioni di qualcosa di già sviluppato
• Categoria B: nuovi sviluppi su tecnologie comunque conosciute
• Categoria C: nuove realizzazioni su tecnologie inedite o sulle quali non esiste in azienda un know-how specifico

Per queste categorie potrebbe essere sintetizzata la seguente tabella.

Le risorse a più alta specializzazione o responsabilità (software architect o project manager) sono quelle a maggior costo e spesso anche quelle meno numerose o disponibili in azienda.

Si pone quindi la forte  necessità di gestire al meglio tali progetti cercando il miglior bilanciamento economico, di risorse e di governo del progetto stesso.

L’obiettivo è molto sfidante e, più di quanto si pensi, rappresenta per una piccola azienda la differenza tra floridità,  mera sopravvivenza o fallimento.
Vogliamo aggiungere a questa considerazione il famigerato peso dell’ “attuale momento congiungurale e di crisi in cui verte l’economia mondiale?”

Già, le vostre preoccupazioni sono anche le mie.

Non posso dire di aver elaborato una soluzione.
Parto però dalla semplice considerazione che senza un metodo, la situazione, già di suo piuttosto complessa, non è risolvibile.
Proviamo a scomporre il problema in aree per cercare di delineare un approccio.
Tali aree le possiamo considerare componenti primarie di un progetto:

• Cultura di project management aziendale e relativo grado di maturità
• Regolamentazione della modalità di lavoro
• Framework metodologico
• Rapporto con il cliente
• Gestione del team
• Gestione del portafoglio progetti

Per ognuna cerchiamo di evidenziarne i punti chiave e i possibili approcci.

Cultura di project management

Non è un lusso. Non è qualcosa di cui possiamo fare a meno.
Non è necessario per riempirsi la bocca di termini molto “professional”; è l’unico modo per crearsi un background che guidi il nostro percorso attraverso le complessità crescenti dei progetti.

Non è pensabile si possano gestire progetti, soprattutto in ambito ICT, senza un’adeguata cultura di project management, dove vincoli stretti e difficoltà in genere sono la quotidianità:  tempi ridotti, budget tagliati, carenza di risorse, complessità comunicative, in altre parole progetti ad alto rischio.

Ecco che quindi il project manger deve conoscere le basi, deve costruire una cultura di project management partecipata dal team, dal management, dal cliente.
Deve creare quel lessico, vocabolario comune fatto di metodi, tecniche, strumenti quanto più possibile condivisi.

Modalità di lavoro

L’esecuzione del lavoro deve essere regolata, incanalata, per certi versi industrializzata.
Un team di progetto, sebbene di una piccola azienda, non può permettersi un approccio artigianale.

O meglio tale approccio, sia chiaro ad altissimo valore aggiunto, può essere mantenuto per quelle attività in cui esiste una forte componente creativa o nelle aree in cui un approccio dedicato, dettagliato, quasi ritagliato sull’esigenza specifica, è un presupposto per la buona riuscita del progetto stesso.

Per tutto il resto devono essere definite regole, metodi, tempistiche, template e layout standard, procedure, persino le modalità di comunicazione con il cliente andrebbero decise a tavolino.

Project Framework

In campo di sviluppo software un framework è una struttura di supporto al lavoro, composto funzioni, metodi, codice, organizzato in librerie riusabili indistantemente dal tipo di applicazione in fase di sviluppo.
Questo concetto è alla base dello sviluppo software: creare codice riusabile, già testato, che garantisce maggiore velocità di realizzazione, costanza di risultati e scalabilità su differenti realtà.

Perchè quindi non creare un nostro project framework? Un componente che racchiuda il nostro approccio ai progetti?

Tutto ciò descritto nel paragrafo precedente potrebbe essere in qualche modo reso astratto, generalizzato e organizzato in linee guida, template, layout, procedure, regolamentazioni, flussi di lavoro.

Che immenso vantaggio ne trarremmo?
Ogni componente del team è finalmente  in grado di lavorare per buona parte in completa autonomia e dedicarsi maggiormente alla questioni a più alto valore aggiunto.
Si passa quindi dal governare il quotidiano a governare le sole eccezioni (Exception management wikipedia).
Sarà anche molto più semplice inserire nuove risorse o spostare le risorse su differenti progetti (crashing, fast tracking) in caso di necessità.

Rapporto con il cliente

A prima vista potrebbe sembare il problema con minore peso specifico.

Quando si parla di conduzione e esecuzione di un progetto, di fatto realizziamo una nuova necessità del cliente, qualcosa che non esite, qualcosa che ha solo immaginato.
Qualcosa alla quale tiene particolarmente e sulla quale sta investendo tempo e denaro, semplicemente fidandosi di una promessa fatta, sulla base di alcuni capitoli scritti in un project plan.
Questo ci investe di una grossa responsabilità; personalmente faccio fatica a caricarmi sulle spalle tali pesi in mancanza di una piena fiducia.

Il cliente deve fidarsi di noi. E noi dobbiamo imparare a conquistarla.

Quando il cliente si fida di noi, diventa un alleato, non un nemico dal quale difenderci stando in trincea; evitaremo di spendere energie per giustificare, spiegare, puntualizzare.
Cominceremo a spostare il rapporto su piani diversi: sinergia e collaborazione.

Gestione del team

Come già accennato sopra, il team deve condividere pienamente modalità, regole e flusso lavorativo.
Deve riconoscere nel project mangaer un leader: una persona capace di fissare mete e obiettivi condivisi, capace di stimolare il lavoro, di motivare continuamente il gruppo e all’occorrenza di personalizzare il proprio stile alla situazione e alle singole persone.

Il successo di un progetto è vincolato alla regola: le persone giuste al posto giusto.
Qualcosa di cui ho già accennato in un precedente post.

Gestione del portafoglio progetti

La definizione ufficiale di portafoglio di progetti è la seguente.

Collezione di progetti raggruppati per facilitarne la gestione al fine di raggiungere l’obiettivo strategico di ognuno e indirettamente massimizzare quello aziendale. Tali progetti accorpati non necessariamente sono tra loro correlati e i risultati dell’uno potrebbero non influenzare quello degli altri.

In altre parole la loro gestione potrebbe correre su linee parallele.

Gestire progetti tra loro disgiunti presenta sicuramente una maggiore complessità, però ha il suo lato positivo.
Questo si chiama bilanciamento.
Potremo bilanciare le risorse tra progetti, rallentando o velocizzando lo sviluppo dell’uno o dell’altro a seconda delle necessità e dei vincoli di ognuno.
Di fatto stiamo diversificando e bilanciando la nostra redditività.
Di conseguenza bilanceremo anche i rischi.

La gestione multi-progetto non è un’attività semplice.
La creazione di un processo strutturato, in continua evoluzione, rifinitura e controllo, rappresenta forse l’unico vero strumento per far fronte a complessità e rischi collegati.