Project Cost Monitoring

In questi giorni ho avuto modo di ragionare abbastanza approfonditamente sul ciclo di vita dei progetti e su quali attività di controllo sui costi sia possibile attivare nelle diverse fasi.

La crisi in cui versano i mercati impatta fortemente, riducendoli, sui budget di progetto. Quanto inizialmente stimato come costi, può cambiare sensibilmente in poco tempo.

Poter valutare in tempi rapidi e con efficienza il livello dei costi, mettendo in atto le famigerate tecniche di earned value, è vitale per qualsiasi realtà piccola o media che sia.

Questo post è disponibile ai soli utenti registrati. La registrazione è libera.

Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.

This post is available only to the registered users (free). Please register using the voice “Administration/Register” on the right side-bar.

Pronti, partenza…..via!

Scrum è una metodologia agile che pone il focus sull’esecuzione incrementale del lavoro (release), in tempi brevi, caratterizzati da grossa coesione e spirito di iniziativa del team.

In fase analitica utilizza linee di comunicazione molto corte e, in fase di sviluppo, tempi decisionali molto brevi al fine di non dover dedicare troppo tempo allo sviluppo di documentazione analitica e reinvestire quel tempo nello sviluppo effettivo del prodotto.

Esistono tre ruoli/figure fondamentali:

• Product owner, colui che è responsabile del prodotto (solitamente il committente)
• ScrumMaster, colui che governa il processo di produzione (project manager)
• Team, gli sviluppatori che eseguono il lavoro

Le features del prodotto solitamente vengono tutte raccolte dallo ScrumMaster a seguito di interviste effettuate con il committente, gli utenti finali, gli stessi membri del team. Questa lista di funzionalità è chiamata “product backlog“.

Il secondo step è di decidere, con il product owner, quali funzionalità enteranno nelle diverse release (deliverable) ; la lista di funzionalità a capo di una release viene chiamata “release backlog“.

A questo punto entra in gioco il team che con lo ScrumMaster assegna priorità alle singole feature della release ed effettua la stima dei tempi per ciascuna.

Finalmente, in funzione del tempo in cui si vogliono suddividere gli sprint (solitamente da 2 giorni sino a 30 giorni), si scelgono le singole features e si raggruppano, appunto, in sprint.

Le singole attività vengono assegnate ai membri del team e finalmente si parte con lo sviluppo.

Scrum Process

 La scorsa settimana abbiamo deciso di utilizzare tale tecnica per un cambio importante di release del nostro framework applicativo che ci supporta nello sviluppo delle soluzioni. L’ultimo intervento innovativo al progetto era stato fatto più di un anno fà e le segnalazioni di anomalie, bug, revisioni o migliorie erano piuttosto corpose.

Io, in quanto product owner, e il mio collega Massimiliano, ScrumMaster, abbiamo fatto la cernita di tutte le possibili features (product backlog) che potevano essere implementate.

E’ stata fatta una prima scrematura (legge 80/20 di Pareto, ricordate?) che ci ha portati ad avere una lista di features più importanti da sviluppare (release backlog).

A quel punto lo ScrumMaster e il team, hanno prioritizzato tali attività e suddiviso in sprint (che per noi era di 2 giorni), terminando con l’assegnazione dei compiti alle singole persone.

A quel punto è stato il momento del via!

Quali i risultati? Beh, oggi ho parlato con Massimiliano per avere un feedback in merito.

Cosa ha funzionato:

• I tempi sono stati rispettati tranne piccole varianze
• Praticamente tutte le feature sono state implementate
• Il lavoro del team a stretto contatto, su tematiche comuni, ha permesso la nascita di buone idee/suggerimenti
• La condivisione e la comunicazione attiva ha permesso di creare persone di backup su alcune aree di codice sino ad allora conosciute solo da singoli

Cosa non ha funzionato:

• Non tutte le persone che inizialmente erano state scelte per far parte dello “sprint team” hanno potuto partecipare attivamente, cause incombenze e urgenze lavorative

In generale comunque possiamo ritenerci soddisfatti.

Il prossimo sprint lo faremo probabilmente il prossimo mese, e lavorare molto di più sulla qualità dei processi che utilizziamo per produrre soluzioni.

ByeBye

Puntiamo al sodo

Per natura ho una certa predisposizione alla pragmaticità.
Nel lavoro raramente pratico il gold-plating e cattedrali nel deserto ne ho costruite ben poche.
Questo approccio prevede una contropartita da regolare: posso perdere alcuni dettagli o sfumature o a volte il mio interlocutore può percepirmi come poco sensibile alle sue istanze più particolari.
Accetto il rischio. Cerco comunque di mantenermi vigile per evitare di commettere tali errori.

Citano alcuni testi di project management: un progetto si può ritenere concluso con successo, quando termina nei tempi e nei costi prestabiliti e quando sono state realizzate tutte le funzionaltà previste e solo quelle previste.

Questa citazione spalanca la porta alle tematiche agili.

Partiamo dal documento costituitente della disciplina agile (manifesto per lo sviluppo agile di software).
In quel documento sono esplicitamente evidenziati i quattro pilastri su cui si sviluppa l’intera disciplina e soprattuto su quali questioni deve essere posto il maggiore accento:

• Gli individui e le interazioni più dei processi e degli strumenti
• Il software funzionante più che la documentazione esaustiva
• La collaborazione col cliente più che la negoziazione del contratto
• Rispondere al cambiamento più che seguire i piani

Nascosta tra le righe io ci leggo una sola parola: concretezza.

Customer Value

La teoria agile mette al centro della sua esistenza il concetto di customer value, che potremmo così sintetizzare:

il giusto prodotto, al giusto prezzo, nei giusti tempi.

Ma come possiamo definire “giusto” un prodotto, il suo prezzo e i relativi tempi di realizzo?

• Il giusto prodotto, è quel prodotto che implementa tutte le funzionalità richieste dal cliente, solo quelle, e che abbiano le caratteristiche e qualità necessarie.
• Il giusto prezzo è quel prezzo, equo e correttamente comparato alle funzionalità, aspettative e al mercato.
• I tempi giusti sono i tempi minimi di realizzo del prodotto, che vadano più possibile incontro alle aspettative del cliente.

Quando lessi la prima volta la definizione sopra, sorrisi: alcune le consideravo definizioni ovvie, altre semplicemente utopiche.

Però mi fecero pensare.

Era in effetti capitato in alcune occasioni, che alla presentazione di un prodotto appena realizzato il cliente mi facesse notare come alcune funzionalità introdotte non le ritenesse importanti; anzi spesso mi chiedeva di disabilitarle per evitare incomprensioni da parte degli altri utenti.
Quanto tempo e soldi mi erano costate quelle inutili funzionalità?

Altro problema centrale rispetto alla soddisfazione del cliente, è il tempo di realizzo di un prodotto o servizio.
Prima però un’altra considerazione a riguardo: sappiamo riconoscere il vero valore di business del prodotto che il cliente ci ha commissionato? Sappiamo identificare le funzionalità centrali del prodotto stesso?
Certo, credo proprio di si; spesso però tali funzionalità sono le ultime, in ordine cronologico, che vengono sviluppate.

Le motivazioni sono valide: è necessario oraganizzare prima il progetto, le risorse, l’architettura e, se si tratta di uno sviluppo software, il database e una buona parte dell’interfaccia utente.
Il cliente, di questo passo, vedrà le caratteristiche primarie del prodotto praticamente alla fine del progetto stesso.

Come fare quindi per conciliare tempi adeguati e soddisfazione del cliente?
La risposta è sicuramente procedere con rilasci progressivi.

Rilasci Progressivi

Il cliente ha appena firmato il contratto che gli abbiamo presentato per la realizzazione del prodotto richiesto.
Qual’è il più classico degli errori in cui ricadiamo?
Sparire per un tot di settimane, per poi ricomparire con il prodotto finito; chi di voi non ci è cascato almeno una volta? Personalmente, nonostante mille auto-raccomandazioni, mi capita tuttora.
Risultati:

• il tempo trascorso senza contatti ha “raffreddato” il cliente
• alcune, se non tutte, le funzionalità del prodotto, non sono come il cliente se le aspettava
• la finestra temporale in cui il prodotto avrebbe riscontrato maggiore successo è ormai passato
• il prodotto dovrà essere testato e sicuramente verranno richieste modifiche o aggiustamenti che avranno una ricaduta pesante considerando che siamo ormai alla fine della sua realizzazione

Ecco allora che lo sviluppo iterativo del prodotto/servizio e la predisposizione di rilasci progressivi di prototipi, perfettamente funzionanti nelle loro seppur parziali funzionalità, potrebbe essere la risposta opportuna.

Come fare?
Prima di tutto partiamo dalla WBS di prodotto: essa ci restituisce uno spaccato preciso e immediato di tutte le funzionalità del prodotto.
Insieme al cliente procediamo a prioritizzarne le funzionalità: partendo da quelle a più alto valore di business.
Queste dovranno essere quelle che andremo a rilasciare il prima possibile, abbattendo rischi di misunderstanding, cercando e ottenendo feedback immediati proprio perché caratteristiche più volute dal cliente, aumentando la soddisfazione del cliente perché indirettamente percepisce di avere il suo prodotto in tempi molto brevi.

In virtù di quanto detto sopra a proposito di architettura e organizzazione del progetto, non è però sempre facile rilasciare subito tali funzionalità al cliente; è per questo che è assolutamente necessario coinvolgere il team.

Solo il team è in grado di fornire indicazioni, suggerimenti, scorciatoie per arrivare a tale risultato.
Ovviamente tutti i mebri del team devono condividere pienamente le motivazioni che portano ad una scelta del genere, pena il fallimento dell’operazione.