Premessa
Ogni persona coinvolta in un progetto -capo progetto, analista, progettista, sviluppatore, tester, etc.- vede le situazioni da un diverso punto di vista: cercheremo nella serie di articoli di questa track di dare informazioni utili a chi ha anche saltuariamente funzioni di capo progetto per l'impostazione, il controllo e miglioramento continuo nella gestione, uscendo dagli argomenti strettamente tecnologici per occuparci di metodologie ed esperienze utili a questo scopo.
L'obiettivo è di fornire informazioni utili, non banali, non accademiche, praticabili se il contesto è giusto, a chi per ruolo deve anche partecipare alla gestione e non solo alla realizzazione tecnica di un progetto.
L'attività di sviluppo software è finalizzata alla creazione di applicazioni.
In funzione di questo obiettivo si creano e si usano metodologie, tecnologie, prodotti, informazioni, si istruiscono e si utilizzano risorse.
Per raggiungere questo obiettivo si muovono persone che hanno lo scopo di decidere se accettare o no di occuparsi di un progetto, quanto deve costare al cliente e a chi lo produce, qual è lo staff migliore disponibile per occuparsene, chi deve occupare i diversi ruoli, quali rischi si dovranno affrontare di tipo tecnologico, di rapporto con cliente, di gestione personale e tecnica del team, di ordine economico, di ordine finanziario, di ordine legale e come affrontare questi rischi.
Spesso lo sviluppo software non arriva felicemente a conclusione: si dilatano tempi e costi, non si raggiungono gli obiettivi, si creano attriti con il committente e all'interno del team che si occupa del progetto.
L'esperienza di molti anni insegna che una buona gestione riduce al minimo i rischi di fallimento totale o parziale di un progetto, e che è proprio la insufficienza di questo aspetto a portare spesso ad un risultato deludente.
Ovviamente non esiste a priori un modo buono ed uno non buono per gestire progetti: le variabili sono così numerose che il lavoro di decenni dei metodologi e decenni di esperienza pratica possono solo fornire strumenti e riferimenti per diminuire i rischi di sbagliare.
Sarà poi lo scrupolo e la voglia di fare le cose bene che permetterà di applicare intelligentemente le varie impostazioni e di usarle con costanza e flessibilità, raggiungendo il miglior risultato possibile.
Già decine di anni fa era chiaro a tutti quelli che se ne interessavano che gestire progetti (che siano software è solo un dettaglio) era un mestiere veramente difficile.
La realizzazione di progetti software è uno dei campi applicativi con un costante un gap significativo tra le migliori pratiche conosciute e la pratica corrente media applicata e, mentre le tecnologie sono cambiate decine di volte, le difficoltà dei progetti sono rimaste le stesse: per cui si può concludere che i maggiori problemi dello sviluppo software non sono problemi tecnici e tecnologici ma problemi di management

Affrontiamo innanzi tutto la relazione tra il Project Management e la gestione del processo software, visto che tra questi due concetti c'è una grande confusione poiché sulla carta, ad alto livello, si occupano dello stesso argomento. Questo è vero, ma solamente in parte, solo se consideriamo un "progetto" ben preciso che è la costruzione ex-novo di una applicazione software. Il Project Management vale anche per tutte quelle attività che hanno uno scopo diverso dalla costruzione di una applicazione: lo studio e la implementazione di una architettura, la realizzazione di un documento tecnologico, la manutenzione di un prodotto software sono tutte attività soggette al Project Management e non alla gestione del processo di sviluppo software.
Il Project Management si occupa quindi di fornire strumenti a prescindere da quale sia il merito del progetto, mentre il processo software si occupa nello specifico dei progetti che hanno come scopo la costruzione di una applicazione software. Molti argomenti sono quindi coincidenti mentre altri, nel processo software, sono unicamente e strettamente validi per questi progetti.
Il Project Management infatti non è una disciplina strettamente collegata all'ingegneria, anche se fin dall'inizio il Project Management apparve soprattutto nelle discipline ingegneristiche: fu facile, imparando dagli errori commessi in quest'area di intensa applicazione, ottenere buoni risultati e identificare il Project Management come una disciplina ingegneristica mentre in realtà è indipendente dal campo di applicazione.

Iniziamo con una definizione di alto livello:

il Project Management è la pianificazione, l'organizzazione, la direzione, e il controllo delle risorse di una azienda per raggiungere un obiettivo relativamente a tempo breve che è stato definito. [Kerzner]

Vanno spese due parole riguardo a cosa significhi obiettivo " relativamente " a tempo breve: nella industria delle costruzioni il tempo breve è da tre a cinque anni, nelle componenti nucleari dieci anni, delle assicurazioni due settimane, nel software dipende. Per essere chiari non è Project Management gestire una divisione di sviluppo software ma l'implementazione di una infrastruttura software lo è.

Quindi potremmo ridefinire il Project Management come: la gestione e il controllo delle risorse affidate ad una certa attività, nel tempo definito, rispettando i costi pattuiti, ottenendo i risultati (cioè raggiungendo gli obiettivi stabiliti) e, se il progetto è per un cliente esterno, mantenendo buone relazioni con cliente.

Il Project Manager è quindi la persona che deve guidare un progetto al successo, definito come il completamento:

• nel periodo di tempo stabilito
• nei costi stabiliti
• a livello di performance stabilite
• con accettazione del cliente o dell'utente
• con un minimo di cambiamenti di obiettivi comunque concordati
• senza disturbare le normali attività dell'organizzazione
• senza cambiare la cultura dell'azienda
• potendo utilizzare il nome del cliente come una referenza

Penso che adesso sia chiaro che questi obiettivi valgono per tutti i progetti inclusi quelli software, e che quindi un certo set di attributi e comportamenti sarà un denominatore comune tra il Project Management e la gestione dei progetti software: definizioni, obiettivi, situazioni, strumenti sono un patrimonio di tutti i tipi di progetto ed in questo il software non fa differenza. La parte tecnica di esecuzione è legata alla area di applicazione ed il processo di costruzione è quindi specifico dei progetti software.

Di cosa si deve occupare il Project Manager per guidare un progetto al successo?
La gestione permanentemente aggiornata della pianificazione rispetto agli obiettivi e l'applicazione di tutti i comportamenti che possono migliorare le probabilità di raggiungere gli obiettivi del progetto.

Due sono i punti salienti della precedente definizione.
Innanzitutto viene messo in evidenza che il Project Manager svolge una mansione in maniera continuativa, cioè la pianificazione: spesso la pianificazione viene vista come l'assegnazione a una o più persone di una attività e l'attesa del raggiungimento dell'obiettivo, mentre in realtà andrebbe interpretata come la definizione di una stima per un'attività, l'assegnazione a una o più risorse, il monitoraggio del progresso dell'attività con il conseguente riallineamento delle aspettative di completamento. Come vedremo successivamente, infatti, possono accadere e quasi sempre accadono eventi che permettono di fare una nuova stima più precisa rispetto a quella corrente.
Il secondo punto riguarda il fatto che il ruolo del Project Manager non si limita ad essere spettatore passivo di quello che succede nel progetto, o a fare pressioni sulle risorse perché completino più velocemente le attività assegnate, ma svolge anche una serie di attività che hanno come obiettivo di migliorare le performance del gruppo, di evitare le deviazioni, le perdite di tempo, il manifestarsi di problemi, visto che soprattutto queste cose aumentano la probabilità di chiudere il progetto con successo.
Durante l'esecuzione di un progetto cambiano continuamente le condizioni al contorno: questa affermazione è tanto più vera quanto più il progetto è di grosse dimensioni, gli obiettivi sono variabili, lo staff non è stabile, la comunicazione con tutti quelli che possono condizionare il progetto è vasta.
Sono almeno quattro le ragioni per cui le condizioni al contorno cambiano pressoché quotidianamente.

1- Avvengono cambi di scenario: possono esserci cambiamenti di strategia , cambiamenti di date di partenza o di fine attività, cambi di obiettivi, variazioni in più o meno di risorse disponibili.
2- Nascono elementi che aiutano a ristimare: visto che le stime vengono fatte sulla base di criteri come la produttività attesa, la produttività storica, le difficoltà tecniche da affrontare,ogni progresso misurabile porta elementi in più che aiutano a qualificare la produttività dei singoli individui sulle attività; se poi sono state fatte variazioni all'organico del progetto (eliminazione, introduzione, spostamento di risorse) i primi dati di produttività nel nuovo assetto permetteranno di qualificare molto meglio le stime.
3- Ci sono esiti di variazioni: anche le modifiche delle condizioni al contorno di un progetto implicano un cambiamento. I canali di comunicazione, l'infrastruttura (cambio di PC, di strumenti di sviluppo, dell'ambiente di lavoro), vengono spesso modificati in corso d'opera ed è probabile che lo si faccia per avere un impatto positivo.
4- Imprevisti: nei primi tre punti abbiamo elementi che tutto sommato possiamo considerare previsti nell'arco di un progetto, e pertanto ci sarebbe da stupirsi se non succedessero. Ci sono però situazioni che nessuno si augura ma che possono succedere ed hanno un impatto forte sull'avanzamento del progetto: l'incidente, la malattia, la situazione familiare improvvisa, l'emergenza di un altro progetto ed altri eventi esterni straordinari obbligano a rivedere le aspettative.

Da questa serie di considerazioni emerge l'essenza del ruolo del Project Manager: occuparsi di avere sempre la situazione sotto controllo per prevedere come il progetto finirà, e fare tutte le attività che possono aiutare a raggiungere gli obiettivi. Non è poco, e sicuramente le competenze che servono per svolgere egregiamente questo compito sono varie. Cerchiamo di dare un ordine logico a quanto emerso.
Sulla base di quanto detto precedentemente possiamo identificare quattro aree base:

La gestione degli obiettivi
La gestione dei tempi
La gestione dei costi
La gestione della qualità

Ci sono altre quattro aree di attività che comunque vanno svolte per aiutare la corretta gestione delle precedenti:

La gestione delle risorse umane
La gestione delle comunicazioni
La gestione dei rischi
La gestione del "procurement" o del reperimento delle risorse (persone e cose)

Risulta sempre più evidente che il Project Manager è prima di tutto un uomo di relazioni: raccoglie permanentemente informazioni tecniche e non, risultati, impressioni e le consolida in delle previsioni che aggiorna di continuo. Attraverso le relazioni con una serie di interlocutori cerca di far accettare idee di cambiamento, cerca di capire cosa crea ostacoli e di eliminarlo, in un continuo compromesso tra il voler far meglio e il fare il possibile.
Gli interlocutori del Project Manager sono normalmente chiamati "Stakeholders". Con questo nome si indicano tutte le persone che sono coinvolte o influenzate dall'attività di progetto: certamente Stakeholders del progetto sono il team, gli sponsor ( promotori e sostenitori), lo staff di supporto, i clienti, gli utenti, i fornitori, quelli che si oppongono al progetto.
Il Project Manager può godere del supporto di varie tecniche e di tools per essere più veloce, preciso, oggettivo nell'esecuzione dei suoi compiti: come in tutte le altre attività tecniche non si può aspettare che i Tools facciano il lavoro ma sono sicuramente di un aiuto decisivo nel farlo meglio. Nella gestione degli obiettivi dispone di WBS e Project Charter, nella gestione dei tempi di Gantt, Pert e Analisi del Cammino Critico, nella gestione dei costi della Earned Value Analysis. Di tutti questi argomenti parleremo nei prossimi articoli .
Una delle ragioni per cui soprattutto nei progetti di medio piccola dimensione di solito non viene formalizzato un ruolo di Project Manager è che non c'è lo spazio di budget per prevederlo; questo porta a far sì che il ruolo di leader tecnico del progetto e se quello di Project Manager vengano riuniti in una stessa persona che ha quindi il gravoso compito di dividersi fra due mansione parecchio diverse. Proprio per la facilità con cui spesso si trascurano i compiti relativi alla mansione del Project Manager è importante capire quanto il Project Management sia decisivo in un progetto: proviamo a mettere in evidenza alcuni degli elementi [Knutson]:

• i capi, i clienti e gli altri Stakeholders non amano le sorprese
• il Project Management ben esercitato rassicura tutti e riduce i rischi
• il Project Management fornisce strumenti ed ambiente per pianificare, monitorare, misurare il progresso, e gestire calendari, risorse, costi, e qualità
• il Project Management fornisce storia e metriche per pianificazioni future e buona documentazione sulle attività svolte
• i membri del team di progetto imparano e crescono di più attraverso lo scambio di informazioni fornite dal Project Management attraverso i suoi strumenti.
  
  

Il Project Management ha una serie di contenuti che sono i componenti fondamentali di questa disciplina, come abbiamo elencato , ma le relazioni con altre aree di conoscenza ed esperienza ci sono e sono forti: in particolare le conoscenze di management e quelle relative all'area di applicazione del progetto ( lo sviluppo software in questo caso) sono indispensabili ed hanno un grande impatto sui risultati anche se il PMGR si differenzia dal manager e dal tecnico perché deve focalizzarsi sul raggiungimento degli obiettivi specifici del progetto.

Per concludere
In questo primo articolo abbiamo cercato di collocare il Project Management all'interno delle discipline che toccano le attività software.
Abbiamo chiarito le differenze tra il Project Management e la gestione del processo di sviluppo di una applicazione, abbiamo definito il Project Management e le sue aree di competenza, di cosa si occupa il Project Manager e cosa ci si aspetta da lui, l'importanza del suo ruolo nei confronti degli Stakeholders, cosa sia un progetto di successo.
Abbiamo cioè creato le basi per affrontare nei prossimi articoli le tecniche di gestione delle varie aree di competenza.

Bibliografia
Harold Kerzner - Project Management 8th Ed. 2003 John Wiley e Sons, Inc.
Knutson Jean - PM Network, Dicembre 1997