Per prima cosa la mia visione: il Project Management è comunicazione.

Quindi la risposta breve alla domanda è: la migliore applicazione di project management è quella che garantisce la miglior comunicazione tra team e cliente. Intendo: all’interno del team e tra team e cliente.

E soprattutto verso il cliente.

Infatti, se i problemi all’interno del team sono risolvibili con la vicinanza (spesso il team è tutto interno all’azienda), la comunicazione “remota” col cliente è il problema più difficile da risolvere, anche a livello di aspettative, percezioni, ecc.

Per questi motivi, da tempo ho scelto Basecamp come applicazione per gestire i progetti, perchè favorisce la comunicazione in maniera orizzontale tra team e cliente. Esistono molti altri tool e applicazioni che fanno cose simili, ma alla fine Basecamp è abbastanza flessibile per fare tutto quello che serve.

In altri casi mi è capitato di utilizzare altri tool più focalizzati sullo sviluppo (i vari Assembla, Trac, CVSqualcosa, etc). La mia idea è che sono troppo focalizzati sullo sviluppo da non essere compresi dai clienti, con il risultato che non li usano.

La comunicazione di un progetto deve essere comprensibile a tutti, altrimenti rimane aperta una pericolosa lacuna.

Comunque, se proprio non puoi farne a meno e scegli un tool focalizzato sullo sviluppo, sincerati che ci siano almeno dei wiki/writeboard e un forum o la possibilità di postare messaggi.

Infine, una serie di cose a cui fare attenzione:

- non limitare i permessi agli utenti (meno limiti più fiducia ottieni, specie verso il cliente)
- non nascondere aree ad alcuni utenti (oltre ad essere tempo perso, riduci ancora la fiducia)
- scrivi spesso tutto quello che fai, anche i piccoli passi (su basecamp utilizzo i messaggi per questo, su assembla c’è la fantastica feature “scrum report” per descrivere quello che è stato fatto ogni giorno)
- lascia che chiunque (sviluppatori, designer, editor) possa rispondere ai messaggi, parlare col cliente, dire la sua
- non aver paura che il cliente veda i draft del tuo lavoro: stimola la discussione ed elimina discussioni future

Infine, ti lascio con le parole dei ragazzi di 37signals:

“We felt strongly that effective communication on a project leads to collective ownership, involvement, investment, and momentum. It gets everyone on the same page working toward a common goal. [...] This vision led us to keep Basecamp as open and transparent as possible. Instead of limiting communication to within a firm, we gave clients access too. We thought less about permissions and more about encouraging all participants to take part. The vision is why we skipped charts, graphs, tables, reports, stats, and spreadsheets and instead focused on communication priorities like messages, comments, to-do lists, and sharing files.” (da Getting Real, 37signals)

Con buona pace del signor Gantt. Amen.

Ultimamente avrete capito che mi piace parlare più di content management framework, che un amico ha ribattezzato publishing framework. Però il mercato dei cms non è per niente morto.

Comunque, trovo molto interessanti i punti 6, 7 e 8 di Seth.

Per prima cosa, quando avete fatto una lista di fornitori, ingaggiate una relazione con le aziende, in modo da capire non solo quali feature differenziano i prodotti dagli altri, ma anche come funziona il loro approccio. Non accontentatevi di documenti descrittivi, insomma, parlate con le aziende e cercate di capire come lavorano, come sviluppano, ecc. Soprattutto, cercate di capire se la metodologia va bene per voi.

Inoltre, fatevi fare dei prototipi e testateli, perchè non è detto che una soluzione ultra-professionale si adatti a quello che serve a voi. Questa cosa è molto intelligente, specie se pensiamo che molti prodotti vengono comparati solo in base a funzionalità e prezzo, ma poi vengono presi un po’ a scatola chiusa.

Infine, provate a progettare un’implementazione. Serve per molte ottime ragioni, tra cui aggiungo il fatto di capire qual’è la portata dei cambiamenti, cosa comportano, come affrontarli, ecc.

Lettura utile per tutti, anche se credo che questi consigli vadano bene per progetti la cui scelta di un cms sia strategica per l’impegno economico e gestionale che richiede. Penso probabilmente a grossi progetti come mega-portali istituzionali, grosse intranet o portali di turismo con budget milionario…

Tra le altre, trovo infinitamente giusta la frase:

The “problems” with almost any process start and end with people.

Ogni volta che mi sono trovato davanti ad un problema, spesso si trattava di un problema relativo alle persone. Una delle seguenti:
- alcuni non si parlavano
- altri si parlavano, ma non si capivano
- molte volte non avevano chiari in mente gli obiettivi
- non erano abbastanza invogliati a prendere iniziative
- non si sentivano responsabilizzati
- ecc

Morale: quando ti trovi di fronte a un problema, non chiederti cosa hai sbagliato. Chiediti chi non sta facendo la cosa giusta e perchè.

Certo, potresti anche scoprire che il problema sei tu. Cosa fare in questi casi? Ne avevo già parlato “anni fa” in un post molto zen. Credo si debba cercare di “spersonalizzarsi” e fare un passo indietro. Ci vuole umiltà, insomma. Eggià.

Lo sviluppo software è una serie di giochi cooperativi di invenzione e comunicazione, con risorse limitate e finalizzati ad un obiettivo. L’obiettivo primario di ogni gioco è la produzione e la consegna di un sistema software; ciò che rimane alla fine del gioco è un insieme di note, utilizzabili per assistere i giocatori del gioco successivo. Le persone utilizzano note e appunti per ricordare, trarre indicazioni e comunicare tra loro, allo scopo di passare alla mossa successiva del gioco. Il gioco successivo è la variazione del sistema, oppure la creazione di un sistema contiguo. Ogni gioco ha quindi come obiettivo secondario quello di conseguire una posizione vantaggiosa per il gioco successivo. Poiché ogni gioco si svolge a risorse limitate, l’obiettivo primario e quello secondario competono tra loro per le risorse disponibili.

Utile, in generale, anche per altri tipi di progetti. Deliverables è la parola chiave del gioco. Come strumenti, vedo bene il wiki. Prima o poi dovrei provare a impostarlo in questo modo.

Questa cosa del gioco, poi, viene fuori spesso ultimamente. Ne parlano continuamente gli anglofoni quando si tratta di fare focus group o altre ammucchiate lavorative.

Se ci penso, durante un recente card sorting estenuante mi sono ritrovato a dire ai partecipanti che dovevano pensare che era un gioco, cercare di pensarlo come uno svago dal loro solito tran-tran quotidiano. E ha funzionato, nonstante lo stress.

Lavorare giocando, lavorare divertendosi. Proviamoci tutti un pochino, dai.

Rock climbers are fond of saying that climbing, done properly, is less dangerous than driving a car.

Io dico invece che si rischia di più andare con lo scooter in tangenziale

Grazie a Ludo per il link.

La risposta, manco a dirlo, viene dal solito polarbear: contenuti e architettura evolvono assieme, man mano che la fase di ricerca e analisi procedono a iterazioni.

Come dire che -in generale- quando vi trovate ad affrontare un problema di questo tipo, la risposta è: ricerca, analisi, iterazione. Piano piano ti trovi l’uovo e la gallina pronti sul piatto.

Certo, non è facile la visualizzazione di un percorso così poco lineare, ma questo è il punto: anche le “metodologie lineari” hanno delle fasi di iterazione (le cosiddette sovrapposizioni tra due diverse fasi sequenziali), altrimenti non funzionano.

Se sei fortemente motivato perchè fare l’analista è la tua passione, contattatami via mail/skype oppure lascia un commento dopo il beep, sarai ricontattato. Se invece non ti interessa, spargi comunque la voce, grazie.

Oggi Gigi Tagliapietra, di ritorno da un meeting in UK, riporta le sue impressioni, che mi confermano quanto siamo distanti dal modello anglosassone, aggiungendo anche molte indicazioni preziose.

I ragazzi di Blue Flavor ci spiegano per benino come stimano i costi di un progetto (leggi bene anche i commenti perchè sono molto interessanti).

L’iniziativa chiarisce ai clienti come si lavora nel mondo 2.0, in quello vero intendo. Qui da noi, anche se spieghi in dettaglio ore e costi, ti chiedono lo sconto. Il principio invece è un altro: ti faccio vedere quanto mi costa, così non discutiamo di sconti, ma di cose da fare e di obiettivi. E questo credo sia un buon punto di partenza per una trattativa: si parla di cose da fare ad un costo ragionevole.

Nel paese dei sogni, forse. Nel paese delle banane senza alberi di banane, il problema è ancora a monte: capire che non si parla di fare solo del lavoro materiale, ma che ci sono persone e aziende che creano valore e per questo devono essere pagate.

Ad ogni modo, negli ultimi tempi ho lavorato stimando i task e le ore di lavoro. Trovo che sia un bel sistema, tranne per il fatto che quando il progetto si evolve è difficile modificare i costi. O meglio, qui in mezzo alle banane, i clienti si aspettano di modificare continuamente il progetto senza che cambi il costo. Non c’è soluzione, ci vuole la capacità di un buon manager e un contratto flessibile.

A tal proposito mi piacerebbe sentire anche la l’opinione di te che non hai un blog e mi leggi di nascosto. Dai amico lurker, lascia un commentino.

• 9 tips for running more productive meetings: più o meno quello che scrivevo qualche tempo fa
• Avoiding Vampire Meetings: per evitare che le riunioni ti succhino il sangue