WeWrite

La rivista che ti ascolta

  • Aumenta dimensione caratteri
  • Dimensione caratteri predefinita
  • Diminuisci dimensione caratteri
Messaggio
  • EU e-Privacy Directive

    Questo sito utilizza cookie, anche di terze parti, per migliorare la tua esperienza e offrire servizi in linea con le tue preferenze. Chiudendo questo banner, scorrendo questa pagina o cliccando qualunque suo elemento acconsenti all'uso dei cookie. Se vuoi saperne di più o negare il consenso a tutti o ad alcuni cookie vai alla sezione Cookie Policy.

    Cookie Policy

    Leggi ulteriori informazioni sulla e-Privacy Directive

Home Società Lavoro Gestione progetto: scope, ruoli, task, comunicazione

Gestione progetto: scope, ruoli, task, comunicazione

E-mail Stampa PDF
(6 voti, media 5.00 di 5)

Gestione progetto: il triangolo dei vincoli di progettoLa gestione di un progetto è un’attività complessa ma imprescindibile per ogni organizzazione.  Se si intende con “progetto” un’associazione temporanea di persone che hanno un obiettivo comune, si può capire quanto vario sia l’ambito di applicabilità e quanta importanza abbiano acquistato le principali tecniche di project management, le metodologie e le relative certificazioni, soprattutto in area IT (Information Technology).

Cosa fa la differenza tra un progetto che ha successo e un progetto che fallisce? Cercheremo di capirlo analizzando lo scope, i ruoli, i task (ossia le attività in carico alle persone allocate) e la comunicazione. Chiuderemo l’articolo con alcuni suggerimenti ricavati dall’esperienza diretta.


Le principali motivazioni per cui un progetto fallisce sono:

  1. Requisiti poco chiari o eccessivamente volatili (errata identificazione dello scope)
  2. Mancanza di chiarezza o di condivisione degli obiettivi
  3. Tempistiche di rilascio non realistiche
  4. Risorse allocate insufficienti
  5. Scarsa comunicazione (o di scarsa qualità)
  6. Scarsa collaborazione tra chi chiede (stakeholder, key user, product owner, cliente – interno o esterno) e chi realizza (team di sviluppo, designer, software architect, dipartimenti a supporto del progetto)


Lo scope di progetto

Tra tutte queste, la parte più importante e spesso sottovalutata è l’identificazione dello scope, ossia l’identificazione degli obiettivi che un progetto si prefigge. Quando lo scope è nebuloso, il progetto è destinato al fallimento.

Gli obiettivi di un progetto devono essere SMART, ossia devono essere:

  1. Specific (specifici)
  2. Measurable (misurabili)
  3. Accessible (accessibili, cioè raggiungibili)
  4. Relevant (rilevanti)
  5. Time-bound (legati al tempo, nel senso di temporalmente definiti, “pianificati” e “pianificabili”)

Se lo scope di progetto non è SMART, fermatevi. Spendete del tempo a definire. Se un cliente (interno o esterno) dice: “voglio tutte le bottiglie uguali”, aiutatelo a specificare meglio. Uguali come? Per colore? Quale colore? Stessa quantità di liquido?
Fate domande. Non sempre è possibile dare risposte nette. Offrite dei range. Tornando all’esempio delle bottiglie tutte uguali. Se si tratta della stessa quantità di liquido, potreste chiedere: “una quantità compresa tra 5 ml e 10 ml?”.

I ruoli

Definire i ruoli all’interno di un progetto può apparire un’attività banale ma è tutt’altro che scontata. Sono le persone a fare la differenza. Spesso il project manager non può scegliere il proprio team, soprattutto in aziende strutturate. Il bravo project manager, però, dovrà essere in grado di capire quali skill, competenze, attitudini individuali tra quelle presenti nel team possono essere valorizzate per conseguire lo scope di progetto.

Non pensate che uno sviluppatore sia soltanto uno sviluppatore, che un esperto di prodotto possa dare solo il proprio know how sul prodotto, che un grafico possa contribuire solo per la parte grafica. Capite le persone che avete davanti. Siate empatici. Anche nelle aziende più strutturate, la definizione dei ruoli e delle funzionali aziendali lasciano zone grigie che possono essere sfruttate dal project manager. Se avete un tecnico che ha lavorato nel business, usate la sua esperienza. Se chi lavora nel finance ha l’hobby del ciclismo e voi state realizzando un sito web che parla di ciclismo, chiedete spesso il suo parere sul prodotto.

Gestione progetto: team e collaborazioneLa rigida definizione degli ambiti di competenza (“questa è la mia parte e mi fermo qui”, “questa cosa la devi fare tu e quindi fammi solo sapere quando hai finito”) fa male al progetto e il project manager ha il dovere di intervenire per abbattere atteggiamenti di chiusura nel proprio ruolo, qualora dovessero verificarsi.

Le persone non sono il loro ruolo aziendale, non sono spazi rigidamente marcati, ma sono entità liquide, in continuo movimento, per interessi, competenze, skill, motivazioni.

Attenzione, però: intervenire per frenare l’atteggiamento opposto, ossia l’intervento eccessivo negli ambiti di competenza altrui, soprattutto se sottendono mancanza di fiducia nelle capacità di un altro membro del team, fa sempre parte della gestione del progetto.

Gli aspetti più importanti sono la collaborazione e la fiducia. Se ci saranno collaborazione e fiducia, i ruoli avranno meno importanza. Si potrà lavorare a “quattro mani”. La gestione del progetto sarà facilitata e più efficace.

I task di progetto

Un progetto è costituito da una serie di attività (i task) che hanno lo scopo di produrre un output ben preciso.

Le metodologie di project management applicabili per identificare ed eseguire i task individuati sono molto diverse. Da quelle a cascata (waterfall) a quelle agili (derivanti dall’Agile Manifesto), al ciclo iterativoNon esiste una metodologia che vada bene per tutto. Dipende dal contesto. Se gli obiettivi sono chiari e le risorse allocabili ben definite, allora un modello a cascata sarà efficace. Se invece gli obiettivi o i requisiti non sono ben definiti fin dall’inizio, allora sarà meglio procedere su ciclo iterativo o in Agile (che sia Scrum, Extreme Programming, Lean Software Development, Kanban o altro). La tempistica di realizzazione è un altro importante fattore che deve essere considerato nell’utilizzo di un approccio piuttosto che di un altro. Se la data di rilascio è essa stessa un requisito (nel senso che è importante rilasciare in o entro una data specifica), allora saranno preferibili metodologie agili o basate su ciclo iterativo. Il rischio da considerare sarà un incremento dei costi, che andranno quindi monitorati con maggiore costanza.

I task devono essere, se non individuati, almeno condivisi da chi fa sviluppo e, in termini più generali, da chi ha compiti operativi sul progetto. È opportuno che le aree operative intervengano fin dalla fase di definizione, per suggerire soluzioni e identificare criticità tecnologiche che possono indirizzare il consolidamento dello scope di progetto.

Pianificate e prendetevi il giusto tempo per farlo. È un aspetto fondamentale del progetto. Non preoccupatevi se il piano cambia. È normale che accada, l’importante è gestire il cambiamento. Procedete per step, non pensate di coprire in modo efficace tutto e subito. Le stime sono stime e la pianificazione basata su stime non potrà che essere rivista. La sfera di cristallo non esiste. Ricordate a voi e ai clienti il cono di incertezza, così come proposto dallo studio della NASA. Il lavoro (o costo) effettivo di un progetto è compreso in un intervallo che va da ¼ a 4 volte la stima iniziale e si riduce in modo asintotico con il proseguire del progetto. La certezza sul lavoro e sui costi si hanno sono a progetto concluso.

La comunicazione

La comunicazione deve essere costante, trasversale, sincera, ma mai aggressiva. Le relazioni devono basarsi sulla fiducia. Preferite comunicare vis-à-vis, se non è possibile parlate al telefono, se anche questo non è possibile, usate una chat. Lasciate le e-email come ultima risorsa o usatele per formalizzare quanto condiviso con altri mezzi.

Non affidatevi interamente ai documenti. Non è possibile documentare ogni cosa. L’eccesso di documentazione è un male, perché la renderà non reperibile e non consultabile. L’eccesso di comunicazione non lo è (quasi) mai. I dubbi di chi realizza sono legittimi. È compito del project manager facilitare le comunicazioni tra chi chiede e chi agisce operativamente per conseguire i risultati.

Riducete le riunioni al minimo indispensabile. Al termine di un incontro, formalizzate condividendo quello che state scrivendo e fatelo insieme ai partecipanti: in questo modo ridurrete al minimo i rischi di fraintendimenti.

Usate strumenti semplici e rendeteli accessibili da tutti in qualsiasi momento. Riducete i verbali e le minute meeting. Le poste non sono mai state un esempio di efficacia aziendale.

Suggerimenti basati sull’esperienza diretta in area IT

1) Ascoltate il team: abbiamo già parlato di come gestire un team e di come aumentare la produttività in azienda. L’ascolto e l’empatia sono la prima qualità che deve avere il project manager.

2) Agite da facilitatore. A tutte le persone che lavorano sul progetto, fate sempre queste domanda: “cosa posso fare per aiutarti?” e “hai degli ostacoli per fare quello che ti sei prefisso di fare oggi”?

3) Usate retrospettive o “lesson learned” per migliorare il lavoro durante il progetto. Non puntate il dito contro qualcuno per addossare colpe e non permettete che venga fatto. Le lesson learned devono essere spunti per migliorarsi, non un atto d’accusa o di manifesta incapacità.

4) Pianificate, ma siate pronti a cambiare il piano in corso d’opera.

5) Identificate i task partendo da quelli più generali e poi frammentateli in unità minori. Chiedete feedback continui a chi deve realizzare il prodotto.

6) Fate domande e siate sicuri che tutti recepiscano le risposte allo stesso modo.

7) Create un clima di collaborazione. Non abbiate paura di intervenire se elementi del team si dimostrano non collaborativi.

8) Gestite le aspettative e scalate solo se necessario.

9) Utilizzate strumenti semplici. Post-it appesi alle pareti, riassunti semplici.

10) Semplificate. Che si tratti di comunicazioni, gestione dei costi, requisiti funzionali o tecnici.


La gestione del progetto migliorerà.


Ivan Libero Lino

WeWrite, anno IV, n. 1, gennaio 2013