Articolo Seminario del 30 novembre

Pubblico un articolo apparso sul giornale di Merate in merito al seminario sul project management, organizzato dall’Albero Logico per il prossimo 30 Novembre.

Il coltellino sWBSizzero (2^ parte)

Questa seconda parte del post sulla WBS si prefigge di affrontare la tematica della stima dei tempi e costi di un progetto.
Parleremo di scomposizione dei work package in attività, di scomposizione dell’attività in sotto attività e finalmente dell’utilizzo delle tre tecniche di stima più usate: analogous estimating, parametric estimating e three points estimation. 

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.

Stakeholders Analysis

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.

Gestione multi-progetto

Le aziende medio piccole, come per esempio la maggior parte delle software house, si trovano spessissimo a dover gestire l’esecuzione di più progetti contemporaneamente.

Tali progetti, nella maggioranza dei casi, richiedono l’utilizzo di differenti tipologie di risorse: sviluppatore junior, sviluppatore senior, software architect o specialist, project manager.

Tali progetti, inoltre, possono avere differenti gradi di difficoltà, redditività e rischi:

• Categoria A: semplici repliche o revisioni di qualcosa di già sviluppato
• Categoria B: nuovi sviluppi su tecnologie comunque conosciute
• Categoria C: nuove realizzazioni su tecnologie inedite o sulle quali non esiste in azienda un know-how specifico

Per queste categorie potrebbe essere sintetizzata la seguente tabella.

Le risorse a più alta specializzazione o responsabilità (software architect o project manager) sono quelle a maggior costo e spesso anche quelle meno numerose o disponibili in azienda.

Si pone quindi la forte  necessità di gestire al meglio tali progetti cercando il miglior bilanciamento economico, di risorse e di governo del progetto stesso.

L’obiettivo è molto sfidante e, più di quanto si pensi, rappresenta per una piccola azienda la differenza tra floridità,  mera sopravvivenza o fallimento.
Vogliamo aggiungere a questa considerazione il famigerato peso dell’ “attuale momento congiungurale e di crisi in cui verte l’economia mondiale?”

Già, le vostre preoccupazioni sono anche le mie.

Non posso dire di aver elaborato una soluzione.
Parto però dalla semplice considerazione che senza un metodo, la situazione, già di suo piuttosto complessa, non è risolvibile.
Proviamo a scomporre il problema in aree per cercare di delineare un approccio.
Tali aree le possiamo considerare componenti primarie di un progetto:

• Cultura di project management aziendale e relativo grado di maturità
• Regolamentazione della modalità di lavoro
• Framework metodologico
• Rapporto con il cliente
• Gestione del team
• Gestione del portafoglio progetti

Per ognuna cerchiamo di evidenziarne i punti chiave e i possibili approcci.

Cultura di project management

Non è un lusso. Non è qualcosa di cui possiamo fare a meno.
Non è necessario per riempirsi la bocca di termini molto “professional”; è l’unico modo per crearsi un background che guidi il nostro percorso attraverso le complessità crescenti dei progetti.

Non è pensabile si possano gestire progetti, soprattutto in ambito ICT, senza un’adeguata cultura di project management, dove vincoli stretti e difficoltà in genere sono la quotidianità:  tempi ridotti, budget tagliati, carenza di risorse, complessità comunicative, in altre parole progetti ad alto rischio.

Ecco che quindi il project manger deve conoscere le basi, deve costruire una cultura di project management partecipata dal team, dal management, dal cliente.
Deve creare quel lessico, vocabolario comune fatto di metodi, tecniche, strumenti quanto più possibile condivisi.

Modalità di lavoro

L’esecuzione del lavoro deve essere regolata, incanalata, per certi versi industrializzata.
Un team di progetto, sebbene di una piccola azienda, non può permettersi un approccio artigianale.

O meglio tale approccio, sia chiaro ad altissimo valore aggiunto, può essere mantenuto per quelle attività in cui esiste una forte componente creativa o nelle aree in cui un approccio dedicato, dettagliato, quasi ritagliato sull’esigenza specifica, è un presupposto per la buona riuscita del progetto stesso.

Per tutto il resto devono essere definite regole, metodi, tempistiche, template e layout standard, procedure, persino le modalità di comunicazione con il cliente andrebbero decise a tavolino.

Project Framework

In campo di sviluppo software un framework è una struttura di supporto al lavoro, composto funzioni, metodi, codice, organizzato in librerie riusabili indistantemente dal tipo di applicazione in fase di sviluppo.
Questo concetto è alla base dello sviluppo software: creare codice riusabile, già testato, che garantisce maggiore velocità di realizzazione, costanza di risultati e scalabilità su differenti realtà.

Perchè quindi non creare un nostro project framework? Un componente che racchiuda il nostro approccio ai progetti?

Tutto ciò descritto nel paragrafo precedente potrebbe essere in qualche modo reso astratto, generalizzato e organizzato in linee guida, template, layout, procedure, regolamentazioni, flussi di lavoro.

Che immenso vantaggio ne trarremmo?
Ogni componente del team è finalmente  in grado di lavorare per buona parte in completa autonomia e dedicarsi maggiormente alla questioni a più alto valore aggiunto.
Si passa quindi dal governare il quotidiano a governare le sole eccezioni (Exception management wikipedia).
Sarà anche molto più semplice inserire nuove risorse o spostare le risorse su differenti progetti (crashing, fast tracking) in caso di necessità.

Rapporto con il cliente

A prima vista potrebbe sembare il problema con minore peso specifico.

Quando si parla di conduzione e esecuzione di un progetto, di fatto realizziamo una nuova necessità del cliente, qualcosa che non esite, qualcosa che ha solo immaginato.
Qualcosa alla quale tiene particolarmente e sulla quale sta investendo tempo e denaro, semplicemente fidandosi di una promessa fatta, sulla base di alcuni capitoli scritti in un project plan.
Questo ci investe di una grossa responsabilità; personalmente faccio fatica a caricarmi sulle spalle tali pesi in mancanza di una piena fiducia.

Il cliente deve fidarsi di noi. E noi dobbiamo imparare a conquistarla.

Quando il cliente si fida di noi, diventa un alleato, non un nemico dal quale difenderci stando in trincea; evitaremo di spendere energie per giustificare, spiegare, puntualizzare.
Cominceremo a spostare il rapporto su piani diversi: sinergia e collaborazione.

Gestione del team

Come già accennato sopra, il team deve condividere pienamente modalità, regole e flusso lavorativo.
Deve riconoscere nel project mangaer un leader: una persona capace di fissare mete e obiettivi condivisi, capace di stimolare il lavoro, di motivare continuamente il gruppo e all’occorrenza di personalizzare il proprio stile alla situazione e alle singole persone.

Il successo di un progetto è vincolato alla regola: le persone giuste al posto giusto.
Qualcosa di cui ho già accennato in un precedente post.

Gestione del portafoglio progetti

La definizione ufficiale di portafoglio di progetti è la seguente.

Collezione di progetti raggruppati per facilitarne la gestione al fine di raggiungere l’obiettivo strategico di ognuno e indirettamente massimizzare quello aziendale. Tali progetti accorpati non necessariamente sono tra loro correlati e i risultati dell’uno potrebbero non influenzare quello degli altri.

In altre parole la loro gestione potrebbe correre su linee parallele.

Gestire progetti tra loro disgiunti presenta sicuramente una maggiore complessità, però ha il suo lato positivo.
Questo si chiama bilanciamento.
Potremo bilanciare le risorse tra progetti, rallentando o velocizzando lo sviluppo dell’uno o dell’altro a seconda delle necessità e dei vincoli di ognuno.
Di fatto stiamo diversificando e bilanciando la nostra redditività.
Di conseguenza bilanceremo anche i rischi.

La gestione multi-progetto non è un’attività semplice.
La creazione di un processo strutturato, in continua evoluzione, rifinitura e controllo, rappresenta forse l’unico vero strumento per far fronte a complessità e rischi collegati.

Negoziazione, networking e compromesso

Voi, in quanto project manager negoziate continuamente.
Negoziate le risorse migliori, tempi di consegna più lunghi, budget più consistenti, maggiore visibilità vostra e del vostro progetto.

Continuamente dovreste fare networking.
La vostra influenza sulle decisioni di progetto deve essere quanto più possibile pubblica, forte, esplicita.
Quando questo non è possibile, può però passare attraverso canali indiretti, percorrere via di comunicazione confidenziali, mirare all’appoggio degli stakeholder più importanti, trovare cioè percorsi per influenzare, di riflesso, le decisioni più critiche.
Superfluo sottolineare che quanto sopra non dovrebbe ledere alcun principio etico.

Continuamente, ahimé, scenderete a compromessi.
Quando la risorsa che vi aspettate venga assegnata al progetto non vi viene concessa, cercate di ottenere un allungamento dei tempi di consegna; quando il ritocco tanto atteso al  budget non è arrivato cercate un maggior coinvolgimento del management, aumentando la visibilità del progetto e indirettamente delle difficoltà in cui vi trovate.

Esiste però un limite per il compromesso.
L’asticella la dovrete fissare voi e non illudetevi: gli altri stakeholder faranno finta di non vederla.
Spesso troppo presi dalle loro problematiche lavorative o eccessivamente coinvolti dai loro interessi, non tarderanno a chiedervi più di quanto potrete concedere e, in alcuni casi, potrebbero addirittura cercare di convincervi che quanto stai per accettare sia un giusto prezzo.

Personalmente sono una persona guidata dall’entusiasmo e molto portata a condividere i miei progetti, partecipare pienamente a quelli degli altri e ad accettare e fare mie le loro sfide.
Faccio però uso del bisturi della critica (nella sua accezione più positiva): lo rivolgo, in primo luogo, verso me stesso, alla ricerca di quelle imperfezioni da asportare chirurgicamente nella speranza di un miglioramento personale sostanziale.
Lo rivolgo con altrettanta precisione verso il mondo esterno.
Non accetto situazioni congeniali solo ad altri, forzature, compromessi in perdita, imposizioni che snaturino me, il mio team o il mio progetto.

Quando mi capitano situazioni come quelle, suona qualcosa. Avverto una dissonanza, qualcosa non torna.
Prendo tempo, ragiono, valuto le possibilità, le convenienze mie e degli altri, i doveri miei e degli altri.

Una volta un cliente, piuttosto importante, per risposta al mio ennesimo no ad una forzatura su un progetto, sorrise e con sarcasmo e voce un pò alterata mi disse che là fuori il mondo è fatto di squali (ndr leggi concorrenti) pronti a sbranarmi in pochi istanti.
Lo so perfettamente.
Quel cliente, come diversi altri, nonostante forti ed espliciti scambi di opinioni e chiarimenti, si serve ancora della nostra consulenza e dei nostri servizi.

M torna in mente uno dei tanti proverbi sui project manager.
La parola più preziosa e meno utilizzata dai project manager è NO.

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.

Il coltellino sWBSizzero

Nel precedente post ho parlato della WBS e delle sue molte applicazioni in ambito di project management.

Mi piace paragonare la WBS al famoso coltellino svizzero; quel coltellino, che nella sua versione originale è dotato di un classico manico rosso, con croce bianca ben in vista, composto da diverse lame e utensili richiudibili.
Spesso sono disponibili, lame a parte, delle piccole forbici, un cacciavite, una limetta, un cavatappi, una penna, un piccolo pettine.

Ecco quindi che potremmo presentare l’equazione: la WBS sta al project manager come il coltellino svizzero sta a MacGyver (ricordate il fantastico telefilm?).

Ecco gli utensili che la WBS ci mette a disposizione:

1. Assegnazione delle responsabilità
2. Utilizzo delle attività scomposte per favorire le stime tempi/costi
3. Totalizzazione dei costi per attività, work package, deliverable
4. Contabilizzazione dei costi per centri di costo (appunto)
5. Analisi degli stakeholders e loro influenza rispetto alla WBS
6. Risk analysis
7. Issue log communication
8. Definizione di un roll-out plan per deliverable

Il processo di ottenimento della WBS è un processo, tutto sommato, abbastanza naturale.

Avendo come base di partenza la risoluzione di un problema, questo viene prima scomposto in parti più piccole, successivamente per ogni sotto-problema si passa alla definizione delle ipotetiche/possibili soluzioni o approcci (brainstorming), tali spunti vengono poi categorizzati e valutati in una visione di pura fattibilità.

Questo processo, spesso iterativo, porta alla realizzazione di un elenco, molte volte strutturato su più livelli, che possiamo definire WBS.

Partendo da quanto ottenuto sopra, si passerà poi alla ulteriore scomposizione dei singoli work package (rami foglia della WBS) in singole attività.

Volendo fare un esempio, nell’ambito della definizione dell’interfaccia amministrativa di un’applicazione software, i work package potrebbero essere i seguenti:

• Gestione delle tabelle anagrafiche
• Gestione dei parametri di sistema
• Gestione degli utenti

Prendendo l’ultimo work package (Gestione degli utenti), l’ottenimento delle attività si ottiene con una successiva iteazione di  scomposizione:

• Ricerca utenti
• Inserimento utente
• Modifica utente
• Cancellazione utente
• Definizione dei permessi e visibilità

Partendo da qui, possiamo finalmente cominciare ad utilizzare i vari utensili anticipati sopra.
In questo post presento il primo: assegnazione delle responsabilità.

Assegnazione delle responsabilità

Spesso la responsabilità di esecuzione del lavoro, si assegna ad ogni singolo work package.

Qualora, però, il carico di lavoro fosse troppo oneroso è ovviamente possibile assegnarlo a più persone, ponendo il focus sulle singole attività.
Ogni persona deve sapere, con certezza e senza alcun dubbio, quale lavoro deve portare a termine, con quali caratteristiche e livello di qualità e in quali tempi.
In questo ci aiuta molto il classico gatt in cui ogni attività è descritta graficamente su un asse temporale e per ognuna viene eseguita l’assegnazione della/e risorsa/e, assegnando in alcuni casi anche il grado di coinvolgimento in percentuale di tempo.

In campo di assegnazione delle responsabilità, l’uso della WBS, è la base per la definizione della matrice delle responsabilità (RACI Matrix). Questa particolare matrice permette di assegnare per ogni singola voce della WBS, una responsabilità di tipo:

• R – Responsible, chi deve svolgere il lavoro e portarlo a termine.
• A – Accountable, chi è in ultima analisi effettivamente responsabile del raggiungimento dell’obiettivo di quella attività. Chi deve validare in ultima istanza, il lavoro svolto dal responsabile sopra descritto.
• C – Consulted, persona che deve essere consultata e con la quale ci deve essere uno scambio di opinioni rispetto a quel task, in quanto particolarmente interessata o qualificata in quell’area.
• I – Informed, coloro i quali devono essere informati sull’esecuzione delle attività correlate (spesso lo sponsor, il line manager o il management)

Nei prossimi post approfondiremo l’uso del pettine e del cavatappi….emmmhh scusate, dell’uso della WBS a fini di stima e totalizzazione dei costi.

La mia preparazione “PMP”

In un precedente post ho riportato le indicazioni base per affrontare la preparazione alla certificazione PMP del Project Mangement Institute.

In questo post, invece, voglio raccontare il mio viaggio verso quella meta, nella speranza che possa fornire qualche indicazione utile per le persone che stanno per cominciare o che si trovano a metà del guado.

Lessi della certificazione PMP sul numero di dicembre 2006 di Computer Programming. Mi informai subito dopo e i primi giorni di gennaio 2007 ero già iscritto ad un corso di preparazione alla certificazione.

Il corso durò da Febbraio a Giugno.
Le lezioni erano fissate a distanza di 2/3 settimane l’una dall’altra: nella lezione, di otto ore, venivano coperti diversi capitoli del PMBOK, con l’ausilio di materiale didattico proprio della società; nelle successive due settimane studiavamo e facevamo un test propedeutico alla lezione successiva.
A Giugno finimmo le lezioni con una simulazione del test di certificazione in cui, per un paio di punti percentuali, non superai l’asticella.

I mesi successivi furono estremamente impegnativi per via di improvvise accelerazioni sul lavoro.
Trovare spazio per lo studio era arduo: riuscivo ad applicarmi solo alla sera dopo cena e alcune ore nel week-end, il tutto quindi andava molto a rilento.

Tra settembre e ottobre, però, riuscii a investire molto più tempo nello studio e a novembre (il 22 lo ricordo ancora…capirete perché) ero davanti al mio computer, per eseguire la procedura di prenotazione dell’esame.
Ricordavo che, dopo aver scelto la sede prometric dove mi sarei recato per l’esame, avrei dovuto pagare e poi avrei potuto terminare la procedura di iscrizione.
Sapevo anche che dopo il pagamento ci sarebbe stata la famosa possibilità di essere estratto per l’ispezione ma, che volete, era solo una probabilità del 15%!

Fui estratto.

Il giorno successivo, dopo averci dormito sopra, lessi con attenzione la procedura di ispezione.
Avrei dovuto preparare tutta la documentazione che accertava sia il percorso formativo, sia quello professionale.

Per il primo era necessario fotocopiare i diplomi scolastici e quelli relativi all’istruzione sul project management.
Per il secondo la cosa si faceva un pò più complessa; avrei dovuto preparare una lettera per ogni progetto dichiarato riportante i dettagli del progetto stesso e il mio coinvolgimento; infine far firmare il tutto ai referenti (clienti) dichiarati nei singoli progetti.

I progetti che avevo portato come testimonianza per le famose 7500 di progettazione erano ben diciasette, avrei dovuto preparare diciasette lettere e chiedere testimonianza di veridicità con relativa firma a dodici clienti (alcuni progetti erano per lo stesso committente).

Fortunatamente quando preparai la mia iniziale lettera di candidatura, avvertii tutti i miei referenti di progetto che li avrei citati e a quale scopo; questo mi permise poi di chiedere loro di fornirmi il supporto necessario per procedere all’ispezione.

Dicembre fu impegnato alla creazione della documentazione e intorno al 10 di gennaio 2008, riuscii a preparare il plico e a spedirlo alla sede europea del PMI.

Passarono all’incirca 2/3 settimana e arrivò comunicazione che l’ispezione era terminata con esito positivo e potevo finalmente schedulare la data del mio esame.
Nel frattempo però da metà novembre a metà febbraio non avevo toccato libro e si aggiunsero anche diversi “doveri” lavorativi che non permisero di riprendere in mano la pratica certificazione PMP sino al settembre successivo.
A metà settembre fissai la data per il 25 Novembre e ricominciai a studiare.

Il 25 mi presentai presso il centro prometric e nonostante alcuni problemi con la lingua aggiuntiva (mi era stato attivato i russo!) riusci nell’impresa e superai l’esame.

Infine per darvi qualche dettaglio anche sullo studio effettuato, ecco le pubblicazioni e tra parentesi il numero di ripassi:

• Le dimensioni del project management – Damiani (una volta)
• PMBOK – PMI (3 volte)
• Project Management: A Systems Approach to Planning, Scheduling, and Controlling – Harold Kerzner (2 volte)
• Project Standard for Project Configuration Management – PMI (una volta)
• Practice Standard for Scheduling – PMI (una volta)
• Practice Standard for Work Breakdown Structures – PMI (una volta)
• Monografie sul critical chain method, critical path method, risoluzione dei confliti (una volta)

Forse troppo, lo so; conosco persone che hanno studiato un paio di volte il PMBOK e hanno dato con successo l’esame, ma io son fatto cosi: le cose le devo fare mie.
L’unico consiglio che mi sento di dare riguarda il kerzner: è un gran libro, leggetelo; riesce a svelare l’aspetto pratico di ogni lato del project management, cosa che il PMBOK, essendo solo una raccolta di linee guida, non fa.