Introduzione
Nell'articolo precedente abbiamo definito cosa sia un progetto e abbiamo sottolineato come, con una visione abbastanza ristretta, spesso si identifichi la creazione di un prodotto software con un progetto.
Lo sviluppo di un prodotto software è sicuramente un progetto. Non va trascurato, però, il fatto che chi si occupa di software ha a che fare con moltissime altre attività che corrispondono come descrizione ad un progetto ma che non consistono nella creazione di un prodotto software. In questo momento ci interessa tenere ancora una visione larga e quindi non restringere l'obiettivo degli articoli ad una sottocategoria di progetti, perché farlo ci porterebbe a sottostimare una serie di aspetti che invece hanno una grandissima importanza.
Se ci fissiamo un attimo sul contesto che normalmente circonda anche i progetti particolari come lo sviluppo dei prodotti software, ci accorgiamo che il contesto in cui si colloca il progetto può avere molte variabili, che obbligano il capo progetto a relazionarsi con l'ambiente circostante che rappresenta una delle variabili a più alto impatto per il raggiungimento degli obiettivi.
Le modalità di creazione di un prodotto software possono essere molteplici: in alcuni casi i requisiti sono negoziabili e in altri casi no, in alcuni casi i tempi di rilascio sono negoziabili e in altri no, in alcuni casi abbiamo libertà di creare lo staff di progetto e in altri casi abbiamo delle risorse - tutte o in parte - imposte, in alcuni casi c'è un committente intrusivo e in altri casi no.
Già queste variabilità mettono in luce come il compito del project manager vada ben al di là del presidio tecnico del progetto e del banale ciclo assegnazione-controllo che normalmente è la punta dell'iceberg visibile dell'attività di cui parliamo.
Il fatto che un progetto non possa essere isolato dal contesto in cui si svolge è una certezza che fu formalizzata negli anni '50, nel momento in cui si cominciò ad applicare il project management ad attività industriali complesse dopo che era stato utilizzato per decenni per gestire e ottimizzare filiere lineari di processi industriali.
L'emergere di questi approcci analitici porta a guardare un progetto da tre punti di vista:

1. la filosofia dei sistemi: consiste nel guardare le cose come sistemi, cioè come componenti che interagiscono tra di loro lavorando all'interno di un ambiente per raggiungere un obiettivo
2. l'analisi dei sistemi: consiste nell'avere un approccio di tipo problem-solving
3. la gestione dei sistemi: consiste nell'esaminare, prima di fare le modifiche al sistema, la parte business, la parte tecnologica e la parte organizzativa

Le fasi di un progetto e il ciclo di vita di un progetto
Il ciclo di vita di un progetto è l'insieme delle fasi che lo compongono; queste fasi varieranno a seconda del progetto e del suo campo di applicazione, ma quelle generali comprese in tutti i casi sono:

1. concepimento del progetto
2. lo sviluppo del progetto
3. l'implementazione del progetto
4. il supporto del progetto

Le prime due fasi appartengono all'attività di fattibilità del progetto. La fase di concepimento consiste nel piano manageriale del progetto: è il caso o no di affrontare questo progetto; ci sono le condizioni organizzative, tecniche, economiche, finanziarie, operative per farlo; effettuare una stima preliminare dei costi; effettuare una stima preliminare ad alto livello dei vincoli temporali.
La fase di sviluppo è quella che normalmente chiamiamo fase di setup preliminare: strutturare il progetto in attività, stimarle dal punto di vista temporale, ipotizzare quali risorse si debbano dedicare alle attività verificandone la disponibilità, occuparsi di tutte le variabili organizzative che saranno necessarie (assegnazione delle responsabilità di progetto; disponibilità di ambienti e infrastruttura), fare una analisi dei rischi del progetto che andranno monitorati, stimare i costi e il cash-flow del progetto.
Le ultime due fasi avvengono se il progetto viene acquisito e quindi appartengono alla realizzazione del progetto.
La fase di implementazione è la realizzazione tecnica dell'obiettivo del progetto: comprende tutte le fasi tecniche di esecuzione (nel caso di uno sviluppo software sarà la creazione dell'applicazione), che vengono svolte utilizzando le tecniche vedremo in seguito.
La fase di supporto o fase di Close-Out parte con il completamento del lavoro, fa l'esame di quanto si è imparato nella realizzazione del progetto che possa aiutare a svolgere i prossimi in maniera migliore, e fornisce gli strumenti richiesti per la gestione successiva di quanto sia realizzato.

Anche i prodotti hanno un loro ciclo di vita, e il System Development Life Cycle (SDLC) è un framework per la descrizione delle fasi coinvolte nello sviluppo e nella manutenzione dei prodotti software. Le fasi tipiche del SDLC comprendono la pianificazione, l'analisi, il design, l'implementazione ed il supporto. Nell'ambito del SDLC ci sono svariati modelli che sono emersi come riferimento e che vengono costantemente messi in discussione ed aumentati. Non è mia intenzione in questo momento entrare nella polemica fra l'appropriatezza o meno dei vari tipi di modelli di SDLC rispetto alle tecniche Agile, perché ora sarebbe una polemica sterile ed autoreferenziata. Il mio obiettivo è invece quello di fornire strumenti perché ognuno di voi possa dare un suo giudizio e applichi - sottolineo per questa fase del progetto - il modello che più ritiene opportuno. Per quanto riguarda i dettagli dei vari modelli di SDLC dei progetti software potete trovare esaurienti e copiosi dettagli nella serie di articoli di Stefano Rossini [Processi e metodologie di sviluppo - Mokabyte - Marzo 2004 e successivi].

Riassumiamo per l'ultima volta la differenza tra il ciclo di vita di progetto e di prodotto:

• il ciclo di vita di progetto si applica a tutti i tipi di progetto, indipendentemente dal prodotto che deve essere realizzato
• il ciclo di vita di prodotto e i suoi modelli possibili variano in maniera considerevole, in dipendenza dalla natura del prodotto (software, documentazione, implementazione di una infrastruttura, etc.)
• la maggior parte dei grossi progetti IT sono sviluppati come serie di progetti
• il Project Management è un'attività che attraversa tutte le fasi del ciclo di vita, di cui l'implementazione è solo una delle quattro parti

Una volta chiariti questi aspetti emerge evidente la considerazione che sarebbe estremamente rischioso affrontare un progetto senza attenersi in maniera rigorosa ad una regola:
il progetto deve passare con successo attraverso ognuna delle singole fasi per poter affrontare la successiva.
Altrettanto evidente è come sia conveniente, se non indispensabile, effettuare una revisione del progetto all'uscita di ognuna delle fasi per poter valutare il progresso, le probabilità di successo e la validità degli obiettivi per cui il progetto è partito.

Per poter gestire con successo un progetto occorre un minimo di comprensione dell'organizzazione all'interno delle quali il progetto si svolge. Le organizzazioni sono strutture complesse ed è compito del project manager comprenderle per poter svolgere efficacemente il suo ruolo. Cerchiamo adesso di formalizzare quattro punti di vista da cui guardare una organizzazione.

Strutturale
Si focalizza sul ruolo e sulle responsabilità, sul coordinamento e sul controllo. Gli organigrammi aiutano a definire questo punto di vista.

Politico
Parte assumendo il fatto che le organizzazioni sono coalizioni composte da individui e gruppi di interesse. Il conflitto e il potere sono i punti chiave di questo punto di vista.

Delle Risorse Umane
Si focalizza sul fornire strumenti di armonizzazione per i bisogni di un'organizzazione e quelli dei singoli individui.

Simbolico
Si concentra sui simboli e sui significati collegati agli eventi che accadono. Questo aspetto pone enfasi sul fatto che ogni organizzazione ha una sua cultura, e che gli ambienti reagiscono in maniera molto diversa agli accadimenti.

La non corretta interpretazione o tenuta in conto di questa complessità di aspetti di un'organizzazione porta molte volte a trascurare aspetti importanti che hanno un impatto decisivo sulla conduzione di un gruppo all'obiettivo: è frequente l'errore manageriale di lavorare unicamente sul punto di vista strutturale compiendo un'omissione clamorosa che produce rapporti difficoltosi, staff difficili da gestire, scontri personali, che sono l'effetto tipico di un progetto che non funziona. Il realizzarsi di questa situazione molto spesso non è inevitabile, ma è anticipabile con una gestione a monte accurata degli stakeholders da tutte e quattro le prospettive precedenti.

Come vedete il ruolo del project manager va ben al di là del compilare un Gantt e rompere le scatole agli sviluppatori per sapere quando finiranno le attività: si intreccia con le tecniche di management e, nel corso degli anni acquisisce dalla filosofia, dalle tecniche di leadership e dalla matematica strumenti sempre più numerosi.

Permettetemi di dedicare la parte conclusiva di questo articolo ad uno strumento che può aiutare, anche senza essere troppo pragmatico, ad assicurare decisione e strategie che hanno una miglior possibilità di successo nell'interpretare i problemi di organizzazione che possono avvenire durante un progetto.
Nei prossimi articoli affronteremo problematiche classiche ed un po' tediose (anche se cercherò di non renderle tali) sul management degli obiettivi, dei tempi, dei costi, della qualità: sono argomenti fondamentali, decisivi, richiesti e vengono normalmente interpretati come "il project management". E' vero ma non è tutto, perché spesso usare solo quegli strumenti porta a fare errori stupidi.

Lo strumento di cui vi parlo sono le leggi della quinta disciplina, tratte liberamente da "The fifth discipline" di Peter Senge, il teorico delle "organizzazioni che apprendono".

1. I problemi di oggi derivano dalle soluzioni di ieri: le soluzioni che semplicemente spostano il problema da una parte all'altra del sistema spesso non vengono rilevate perché chi ha risolto il primo problema è una persona diversa da chi ha ereditato quello nuovo.
2. Più spingete avanti, più il sistema spinge indietro: se non valutate correttamente gli effetti collaterali di un'azione che intraprendete, creerete facilmente un problema più grosso di quello che volevate risolvere.
3. Prima di peggiorare il comportamento migliora: di strumenti di misura tradizionale possono portare spesso a credere che le cose stiano andando meglio per via di una nuova strategia implementata, ma tuttavia raramente gli strumenti permettono di predire accuratamente le caratteristiche future degli andamenti.
4. La via di uscita più facile di solito riporta all'interno del problema: è sicuramente più semplice curare gli effetti che non le cause di un problema, ma farlo non elimina la presenza del problema.
5. La cura può essere peggiore della malattia: si spiega da sé.
6. Più rapido è più lento: ogni organizzazione ha una sua velocità ottimale per fare le cose, e non si può cercare di forzare la velocità per ottenere risultati che sono irraggiungibili.
7. Causa ed effetto non sono strettamente connesse nel tempo nello spazio: tradizionalmente nel planning e nel problem-solving una soluzione standard è "se facciamo questo alloro otterremo quello". In realtà dobbiamo invece considerare il problema nella sua complessità per assicurarci che quello che facciamo non abbia ripercussioni negative su altri aspetti che sono pure importanti per raggiungimento degli obiettivi.
8. Piccoli cambiamenti possono produrre grossi risultati, ma le aree in cui si possono verificare gli effetti migliori sono spesso quelle meno ovvie: quali possono essere le conseguenze a lungo termine di non prendere decisioni difficili e importanti ora, ma di lasciare andare avanti le cose come stanno?
9. Potete avere la torta e mangiarla - ma non subito: molti dilemmi apparenti sono prodotto del modo statico di vedere le cose. Spesso le scelte rigide del tipo "o/o" sono frutto del non guardare le cose nel loro sviluppo temporale, e non è detto che ciò che non è possibile fare per domani non sia utile comunque dopodomani.
10. Dividere un elefante in due non dà due elefantini: in poche parole spesso divide un problema nelle parti che lo compongono fa perdere il senso del tutto e mette in una strada senza uscita.
11. Non ci sono colpe da attribuire: spesso si tende ad attribuire la responsabilità dei nostri problemi a circostanze esterne. Il pensiero sistemico dimostra che non c'è un vero "esterno": tanto noi quanto la causa dei nostri problemi facciamo parte di un sistema, e quindi la cura va ricercata nel modo in cui noi teniamo rapporti con il "nemico".

Sono sicuro che alcuni di voi sorrideranno, altri riterranno che si tratta di affermazioni banali e non sempre valide: sicuramente la forza delle immagini è tipica del pensiero americano, ma mi è spesso stato estremamente utile usare questo elenco come check-list nel momento in cui ci sono da prendere decisioni delicate durante il corso di un progetto. Tutto sommato queste "leggi" sembrano un ottimo estratto di esperienza e di buon senso, che è la qualità che di solito scarseggia nei momenti difficili.

Bibliografia

Russel D.Archibald - Managing High Technology. Programs & Projects - 1985
Peter M. Senge - La quinta disciplina Sperling & Kupfer Editori - 1992
Stefano Rossini - Processi e metodologie di sviluppo - Mokabyte.it - Marzo 2004 e successivi