Perché i progetti informatici falliscono? Perché tante lacrime, soldi, notti in bianco e consulenti buttati via? A che servono le tecniche di project management allora?
La risposta sta nella prospettiva con cui guardiamo i progetti: a noi sembrano delle attività organizzate per realizzare qualcosa di utile, ma per un dirigente IT un progetto è uno strumento per la gestione del proprio portafoglio di relazioni e di potere. A volte si acquista più potere con un fallimento, specie se il fiasco assume proporzioni immani.
Scrive Paul Murphy spiegando le tecniche per affondare un progetto IT:
There are lots of good ways, but a personal favorite involves under powering the server and then spending as much of the budget as possible on consultants hired to make it work.
Le regole base:
- gli utenti sono sempre ostili al cambiamento
- hai una sola occasione per fare una buona impressione con loro
- assicurati abilmente un fiasco iniziale addossando la colpa ad altri
- presentati come il salvatore degli utenti dopo il primo fiasco
- assumi consulenti costosi e teatrali che bivacchino nella tua sede con notebook, proiettori e cellulari sempre accesi
- convinci gli utenti e i loro capi che la colpa è di Oracle, di Sun, di HP o chicchessia
- convincili che tu stai salvando il progetto mettendo a disposizione macchine e i migliori esperti di della materia direttamente dal tuo budget
Il progetto fallirà con un rumore assordante, ma tu avrai guadagnato la fiducia degli utenti, gestito fortune finanziarie e scaricato tutte le responsabilità sui fornitori.
Lo spostamento di punto di vista dall’obiettivo di progetto al tornaconto individuale, sfruttando la psicologia dell’utente, è interessante. Si è più disposti a dare fiducia a una persona concreta che sembra proteggerci dalla minaccia indistinta del cambiamento, mentre i valori del miglioramento di processo, dell’efficienza e del risparmio sono molto più astratti e impersonali, difficili da fare propri.
Perché quindi aderire a un progetto di successo?
No related posts.








