Playing Collaborative Games

It often happens that I teach in IT and project management courses.
What I’ve experienced is that one the of hardest thing to do in those situations, is to maintain high the level of interest and concentration of the attendees, allowing them to gather the greatest benefit from the course itself.
Actually there’s a secret…let them play!

---

On january I was in Scotland to attend to the SCRUM Master Certification Training Course.

In that occasion Simon, the trainer, organized some interesting games where the attendees, me included, were physically involved.
As usualy happens we were initially reluctant, but once the ice was broken the involvement of each one was really high, as well as the enthusiasm for the results.

Another occasion during which the collaborative games were used as training tools, was during the Italian Agile Coach Camp in Umbria. Unfortunately, I did not participate to those games because contemporarily there were other interesting tracks and I could not avoid to participate; it was really a pitty!

But, lucky me, we had retrospectives about those game sessions and I had the possibility to understand the actual worth of doing those games.

Both the two occasions were triggers for me. They helped me to deeply understand what such a powerful tool the collaborative games is!

Why?!?

1. First of all, they are games. People love to play games, even more if their company pays for it!
2. Second, players have still to pay for playing: you pay, leaving your comfortable zone and putting yourself into a new situation.
3. Third, the attendee is physically, not only mentally, involved. This helps the process of learning and facilitates the brain to store and consequently to remember and recover it.
4. Fourth, is a stimulus for the attendee to immediately activate the passive knowledge s/he has just learnt listening to the trainer.
5. Fifth, a game establishes a cheerful environment and creates a team building effect.

In other words, playing games help us to better understand because of the short feedback cycle (it sounds familiar, doesn’t it?).

Playing collaborative games is a quite sure way to energize the attendees, having them concentrated during the entire course. Which games I used to play in my courses?

A must game is the penny game, but also the specifiers and doers game using a set of role cards to introduce biases or, again, the alphabet games to consolidate what was learnt and the planning poker game.

Furthermore, I also use information radiators such as whiteboards, flipcharts, note cards stuck on the walls,  a task kanban board that shows the progress of each topic of the course, which helps the attendees to see progresses.

A successful and sustainable way to manage projects

What if a project management methodology will offer the possibility to be more efficient in conducing projects and, in the meanwhile cutting off paper, energy and time consumption?

---

This is a tough era for a project manager.

Customers ask for better products, having less time available and with tight budgets.

The latest researches in terms of projects success (Standish Group, CHAOS Report 2009), shows that there’s a high percentage of projects that continue to fail (24%) and another 44% that are challenged. In other words: the customer expectations not ever (almost never) satisfied.

The main problems of those bad projects results, can be summarized as follows:

• Ineffective gathering requirements analysis (ambiguous or missing requirements, misunderstandigs, etc.)
• Bad requirements prioritization
• Continuous scope changes
• Lack of customer engagement and relative feedback
• Late deliveries and slow time to market

Why not considering agile as a possible answer? Yes, of course, agile!

Do you remember the agile manifesto?

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Main advantages:

1. The iterative and prototyping approach lets you to figure out, in advance, if the requirements you collected, are well understood and implemented; that aims to a general risks reduction.
2. Thanks to a well structured approach in prioritizing the customer/user necessities, avoiding of low/unuseful features implementation.
3. Thanks to a closely customer engagement, the feedback loop is reduced consistently.
4. Thanks to short deliveries and prioritization of the features, the customer is able to gather faster business results and ROI.
5. Thanks to short communication’s lines, team members co-location, free project’s information accessibility, the misunderstandings between the several stakeholders, are greatly reduced.
6. The scrum time-box approach, allows the members to be more focused and committed, not wasting time for ineffective meetings.
7. The short feedback loop gives an immediate evidence of problems and bugs, heavily reducing the reworking activities

Furthermore.

Take a moment considering that the optimizations derived from the points above, will aim to:

• reduction of the possibility of errors and consequent reworking (saving time and money)
• reduction of the compiled documentation (saving time, money and avoiding paper and ink consumption)
• reduction of sunk costs (cost deriving from meeting, travels, communication costs, etc.)

Can you evaluate what quantity of carbon monoxide won’t be produced?

Think green, be agile!

Il vero valore di una certificazione professionale

Sull’onda del precedente post, ecco alcuni pensieri in libertà sul valore effettivo delle certificazioni.

---

Già nel “lontano” 1999, quando presi la mia prima certificazione (Microsoft Certified Professional in SQLServer), alcuni dei miei colleghi/amici mi prendevano in giro, dicendomi che stavo sprecando il mio tempo.

Sostenevano infatti che nel concreto mondo del lavoro, conta cosa effettivamente sai fare, rispetto a cosa dici di saper fare, semplicemente perché avevi superato con successo un esame.

Sottile, ma significativa differenza.

A quei tempi ero, e lo sono tuttora, d’accordo con quei colleghi. Cercavo però di spiegare loro, che io quel determinato prodotto (SQLServer, allora) o quella particolare disciplina (SCRUM piuttosto che PMP, oggi), l’avrei studiata comunque, tanto valeva “agganciarci” la certificazione.

Una questione di puro pragmatismo, insomma.

Oggi però le certificazioni si moltiplicano. Ed ecco che noi, poveri professionisti, ci affanniamo nel capire inanzitutto dove il mercato stia andando (Agile PM? SCRUM? Kanban? SCRUMban? Lean?) per poi decidere se provare o meno la certificazione in quella direzione.

Ed ecco che, anche in queste situazioni, un pò di sano project management applicato alle certificazioni, potrebbe aiutarci:

• Quanto tempo dovremo dedicare ad ognuna?
• Quanto costerà preparaci e perseguirla (libri, corsi, esame, eventuali viaggi)?
• Quali sono i rischi di non riuscirci?
• E quali invece, i nuovi positivi scenari (ROI) o opportunità, che si potrebbero dispiegare davanti a noi?

Attenzione. Potremmo cadere nell’errore di valutare quest’ultimo punto, solo in termini economici.

Il ROI che ne ricaveremmo dalla singola certificazione, lo penserei invece come ad  un insieme di singole componenti appartenenti a due aree specifiche: sfera personale e sfera lavorativa.

Sfera personale:

• Ampliamento esperienza cognitiva derivante dallo studio e dall’apprendimento
• Aumento indiretto dell’autostima
• Aumento delle possibilità di networking

Sfera lavorativa:

• Data la possibilità di praticare organicamente la disciplina, riusciremo a meglio dimostrare il nostro valore sul campo
• Riconoscimento oggettivo della professionalità, derivante dal titolo della certificazione stessa
• Vantaggio competitivo sul mercato

In generale possiamo dire che la semplice esperienza della certificazione, se ben vissuta, potebbe valorizzarci contemporaneamente come persone e come professionisti. Questo, di fatto, ci aprirà “abbastanza“ automaticamente nuove possibilità lavorative.

Ecco spiegata la mia passione, innanzitutto per il project management e poi, perché no, per le certificazioni in quel campo!

—

PS: Quell’abbastanza sopra riportato è virgolettato perché, in un contesto lavorativo in cui la meritocrazia è uno dei pilastri portanti per l’avanzamento di carriera, sarebbe un automatismo e quella parola completamente da eliminare.

E in Italia? Beh, lasciamo perdere

prova

 

La gestione del tempo

Saper gestire il proprio tempo è fondamentale per qualsiasi manager, ancor di più per chi gestisce progetti. Saperlo fare bene è capacità di pochi e quindi, di riflesso, se impariamo, sarà un grosso vantaggio competitivo!

---

Il mondo “tecnologicamente avanzato” che viviamo oggi, ci permette di svolgere, in pochissimo tempo molte attività.

Attività che, sino a qualche tempo fà, oltre ad aver richiesto molto più tempo per essere gestite, ci avrebbero obbligato a spostamenti frequenti da un posto all’altro (con inevitabile conseguente perdita di tempo, appunto).

 Esempi di questo dono dell’ubiquità tecnologica, potrebbero essere: chattare e ricevere email sul telefonino, gestire dal palmare appuntamenti e riunioni, ordinare materiale da internet, effettuare teleconferenze con l’estero e via via continuare, sino ad arrivare alle 18.30, alla spedizione dei fiori, ovviamente via internet, a vostra madre per il suo compleanno.

 

 

Certo, dovremmo fermarci e ragionare ogni tanto, sull’effetto disumanizzante che queste pratiche portano con sé. Non essendo però lo scopo di questo post, lascio ad ognuno di noi, nel suo privato e alla sua personale sensibilità, l’occasione di farlo…..ovviamente tra un’email e l’altra

 I vantaggi che la tecnologia ci offre in tal senso, sono dovuti in primo luogo, alle immense capacità che oggi abbiamo nel ricevere informazioni.

Pensiamo infatti a quanto, negli ultimi anni, sia più semplice ed economico, ottenere informazioni grazie ad internet. Questo ha di fatto permesso la proliferazione delle fonti che erogano informazione e degli strumenti che permettono di fuirne.

 Oggi riusciamo a ricevere email, appuntamenti, leggere eBook, manuali o quotidiani e utilizzare intere applicazioni aziendali, sul palmare, iPad o netbook che sia.

 Sono pochi i posti pubblici dove non è presente una rete wireless e se anche sfortunatamente ci trovassimo in uno di quelli, potremmo sempre attivare una connessione internet sul ns telefonino, grazie alle tante offerte dei vari operatori telefonici.

Insomma, siamo eternamente connessi: ad internet certo, ma ancor di più, alla nostra globalizzata rete di contatti, lavorativi e non.

Ed è proprio a questo punto, che nascono i problemi. L’eccesso di informazioni, non correlate tra loro, derivanti da diverse fonti, aumenta vertiginosamente complessità e entropia della stessa e di conseguenza non siamo nelle condizioni di poterla gestire nel migliore dei modi.

 Quante volte avete terminato la giornata verificando che pur non essendovi fermati un attimo, avete fatto la metà delle cose importanti che avreste realmente dovuto fare?

 

Driiiiiiiinnnn! 

 

Eccolo. Questo è il primo sintomo di un’erratta gestione del tempo (o delle vostre attività, che poi altro non sono che facce della stessa medaglia). 

Il mio personale ispiratore in tal senso è Pareto e più in dettaglio uno dei suoi più famosi principi.

Egli infatti ha dimostrato che per alcuni fenomeni vale la regola 80/20: buona parte degli effetti riscontrabili in un fenomeno (80%), lo si deve a un numero piuttosto ristretto di cause (20%).

Gli esempi si sprecano:

• Qualità: l’80% dei difetti è riconducibile al 20% delle cause.
• Economico: l’80% della ricchezza è detenuta dal 20% della popolazione
• Ambientale: l’80% dell’energia mondiale è consumata dal 20% della popolazione
• Sociale: il 20% delle amicizie che abbiamo ci da l’80% della soddisfazione
• Lavorativo: l’80% delle email vengono spedite al 20% delle persone in rubrica

Ce ne sono di diversi altri, ma riguardo alla gestione del tempo e alle attività quotidiane, come si applica Pareto? 

  

L’80% dei risultati è raggiungibile
grazie al 20% delle attività. 

 

Eccola qui la risposta. Basta fare il 20% delle giuste attività per arrivare ad ottenere l’80% dei risultati che tanto rincorriamo. Ma come fare solo quelle giuste?

Beh, è solo un discorso di priorità.

 

Applichiamolo ad un progetto. 

Innanzitutto, a giornata lavorativa appena cominciata, quando sedrete davanti alla vostra scrivania, dovreste annotare in un foglio di Excel quali sono tutte le attività da svolgere nella giornata stessa. Non è necessario dare alcuna importanza alle stesse, fate un sano brainstorming e buttate giù tutto. 

Aprite il vostro foglio di analisi dei rischi del progetto che state seguendo, cominciate a scorrere la lista dal rischio più importante. Verificate se per ognuno di quei rischi, vi siano delle attività che dovreste/potreste svolgere oggi per gestirlo al meglio. Scrivete quelle attività nel foglio di Excel. 

Aprite il vostro client di posta elettronica, scorrete l’intera lista di email riguardante il vostro progetto, verificatene urgenza, priorità, mittente e sua importanza (avete fatto la stakeholder analysis, vero?). Non rispondete ancora ad alcuna email, semplicemente annotatevi di farlo e scrivete, sempre in Excel, quali attività derivano da esse. 

Aprite il vostro project plan e verificate se vi sono scadenze in vista, attività in ritardo, milestone importanti da gestire. E, ancora, annotate eventuali attività nel vostro foglio. 

Ora alzatevi, si dai alzatevi! Andate dal team (che dovrebbe essere a pochi metri da voi, se state applicando i dettami della disciplina agile) e svolgete lo SCRUM Daily Meeting  facendo le tre domande canoniche ad ogni membro: 

• quali task hai concluso ieri?
• quali task hai intenzione di chiudere oggi?
• quali ostacoli ti si sono presentati?

La risposta a quest’ultima domanda è fondamentale. Ricordate: voi siete la persona deputata a risolvere i problemi e a togliere di mezzo gli ostacoli che via via si presentano. Segnate quanto è emerso dal meeting nel vostro foglio di Excel (ricordate il tempo dedicato a tali meeting, per SCRUM, non può durare più di 15 minuti). 

Ora arriva il momento più importante: dove assegnare la priorità ad ogni elemento presente nella vostra lista. 

Le priorità dovrebbero essere assegnate tenendo sempre in considerazione i quattro vincoli di progetto: tempo, costi, qualità e ambito di progetto (funzionalità e caratteristiche da implementare). 

Queste quattro componenti infatti, mappano indirettamente gli obiettivi che il progetto dovrebbe/deve raggiungere.

Qualsiasi attività presente in lista, la cui errata gestione potrebbe mettere a rischio un’obiettivo di progetto, dovrebbe essere catalogata come prioritaria. 

Fatto questo primo passo, si procede con l’assegnare un indice di priorità (da 1 a 10) e finalmente, grazie all’ordinamento di Excel, scopriremo quali attività dovremmo gestire immediatamente!

La mia esperienza mi ha insegnato che alla fine dell’ordinamento delle attività per priorità, la più importante è sempre, e sottolineo sempre, un’attività rognosa, anzi rognosissima. Della serie: fare un meeting con una persona “difficile”, cercare di interpretare i requirements applicativi a partire da un’email di due righe, abbattere il rischio di  un evento catastrofico che sappiamo essere impossibile evitare.

Beh, mettiamoci il cuore in pace e partiamo sempre e comunque proprio da qui (è proprio questo il segreto!). 

E infine, sapete quella storia del professore che voleva insegnare ai propri allievi come gestire il proprio tempo e le proprie attività con l’esperimento dei sassi, della ghiaia, della sabbia e dell’acqua in un contenitore?

Vi rimando a questi due link (Link 1 e Link2) per la storia, altrimenti sarebbe troppo lunga da scrivere.

 Bene, ora non vi aspetta che identificare le cose veramente importanti da fare (il 20% di Pareto o i sassi dell’esempio), per ottenere l’80% dei risultati!

bye-bye

Influenza delle organizzazioni aziendali nella gestione dei progetti

Quanto il contesto aziendale condiziona l’esecuzione del progetto? 

Che difficoltà può incontrare il project manager se lavora in un’organizzazione aziendale strutturata per funzioni invece che per progetti?

---

 

In questi giorni sto conducendo alcune sessioni di corsi di project management in una importante multinazionale che eroga servizi finanziari.

Durante lo svolgimento sono nati spunti di confronto e discussione molto interessanti.

Quelli che sono apparsi più “spinosi” in quel contesto, riguardano il ruolo delle persone incaricate a seguire i progetti, la loro influenza sull’organizzazione e il grado di autorità decisionale che si trovano ad avere.

L’azienda in questione è strutturata per funzioni: organizzazione in cui esiste un functional o line manager per ogni  divisione e in cui lavorano persone che oltre alle attività quotidiane, possono essere incaricate come project leader o come team member per l’esecuzione di progetti.

Progetti che alcune volte sono interni ad un unica funzione aziendale oppure a più ampio respiro, coinvolgendo più funzioni.

Questo tipo di organizzazione, dal punto di vista del PMBOK, è riconducibile al tipo di organizzazione a matrice debole.

Le possibili “configurazioni” identificate dal PMI sono le seguenti:

• Funzionale
• Per Progetti
• Matrice Debole
• Matrice Bilanciata
• Matrice Forte

Tipologia di organizzazioni

 

Organizzazione Funzionale

I progetti in queste aziende vengono gestiti separatamente in ogni funzione, nessuno sharing di risorse tra divisioni differenti e neppure alcun obiettivo comune da perseguire attraverso progetti.

Il project manager non esiste perché il responsabile è il functional o line manager della funzione aziendale in cui si svolge il progetto.

Autorità del P.M.	Nessuna
Disponibilità Risorse	Scarsa
Controllo Budget	Functional Manager
Ruolo P.M.	Functional Manager

 

Organizzazione per Progetti

Organizzazione di questi tipi lavorano per progetti, non per funzioni.

Il project manger ha un elevato grado di autorità e indipendenza decisionale.

I team hanno ottima cultura di project management e i membri degli stessi, sono facilmente intercambiabili gli uni con gli altri.

Autorità del P.M.	Alta
Disponibilità Risorse	Alta
Controllo Budget	Totale
Ruolo P.M.	Full-time

 

Organizzazione Matrice Debole

L’azienda è organizzata per funzioni, ma i progetti possono interessare orizzontalmente più divisioni e quindi includere persone appartenenti a funzioni differenti.

Non esiste un vero project manager, bensì un coordinatore facente parte di una determinata funzione aziendale, il quale fa riferimento al responsabile di quella unità.

Autorità del P.M.	Limitata
Disponibilità Risorse	Limitata
Controllo Budget	Functional Manager
Ruolo P.M.	Part-time

 

Organizzazione Matrice Bilanciata

Struttura identica alla precedente,  il coordinatore, in questo caso project leader, però ha una autorità riconosciuta e con una sufficiente dose di autonomia.

Sebbene la persona appartenga ad una determinata funzione aziendale, il project leader per tutta la durata del progetto non deve rispondere al proprio resonsabile di funzione.

Autorità del P.M.	Media
Disponibilità Risorse	Bassa
Controllo Budget	Misto
Ruolo P.M.	Full-time

 

Organizzazione Matrice Forte

 Queste sono aziende che prevedono una funzione dedicata al project management. A questa funzione appartengono i project manager, ai quali vengono assegnate risorse provenienti da altre funzioni aziendali.

Autorità del P.M.	Moderata
Disponibilità Risorse	Moderata
Controllo Budget	Totale
Ruolo P.M.	Full-time

 

Considerazioni sulla matrice debole

Autorità e risorse a disposizione

Il team leader incaricato del progetto, riceve in “dote” i membri del team con ristrettissime possibilità di scelta o di negoziazione di altre risorse. Tali risorse vengono cedute al progetto per durata ed orari circoscritti e con calendari “difficili”.

Le persone assegnate al progetto, non essendo dedicate completamente allo stesso, rimangono di fatto in carico alla funzione aziendale e a quella funzione devono dare risposte e fornire risultati e solo nel tempo libero (ma quale tempo libero?)  dedicarsi al progetto.

Comunicazioni

Comunicazioni difficili dovute principalmente al fatto che non esiste una “war room” dove il team si incontra e lavora fianco a fianco. I documenti di progetto, le comunicazioni non sono centralizzate, ma vengono condivise attraverso email spedite a tutti i partecipanti.

Questa situazione genera in breve tempo confusione, malintesi e entropia che possono portare i membri del team, alla disaffezione nei confronti del progetto o alla difficoltà di focalizzazione sulle attività in carico ad ognuno.

Performance

Non avere contatti diretti e frequenti con il team, ha impatti sostanziali anche sulle performance.

In situazione normali, infatti, la vicinanza permette al pm di avere riscontri diretti su eventuali problemi  e di ricevere informazioni rispetto allo stato di avanzamento delle attività in carico ad ogni team member. 

Disporre di poche risorse, con disponibilità temporali ridotte, limita notevolmente la possibilità di condurre attività di Earned Value (stati di avanzamento lavori) puntuali e precise che indicherebbero con buon anticipo eventuali ritardi sul pianificato.

Inoltre, non disporre di dati sulle performance impedisce di fatto ai project leader incaricati, di produrre reportistica riugardante stime a finire sia in termini di tempi sia di costi.

Cultura di project management poco sviluppata

Capita che in organizzazioni come queste, non sempre si percepisce la necessità di sviluppare una cultura aziendale di project management.

Questa situazione è rispecchiata direttamente dalle performance dei progetti che spesso ritardano la loro messa in produzione, accumulano costi eccessivi rispetto al pianificato, non raggiungono tutti gli obiettivi prefissati oppure non producono risultati della qualità attesa.

Trend che fortunatamente sta invertendo la rotta, almeno nell’azienda con la quale sto lavorando in questi giorni.

Lì infatti, si sta cominciando a lavorare con convinzione e determinazione in quella direzione.

Sviluppo del team

A seguito di un team “disgregato“ e della poca autorità riconosciuta, è arduo mettere in atto attività di team building, di crescita o formazione del team.

Cosa fare, allora, in quei casi?

Beh, in quei casi anche il singolo può fare molto, considerati i vasti spazi disponibili in azienda in quel campo.

Il primo passo, il più importante, è studiare, informarsi e perché no fare un corso.

Applicare quotidianamente ciò che si è imparato e cominciare ad ottenere qualche risultato positivo, anche piccolo ma che si innalzi rispetto alla media aziendale.

Ecco che allora, diverrete un punto di riferimento per i vostri colleghi e di lì a poco anche il vostro capo comincerà a chiedersi come fate!

…stay tuned!

Articolo sulla qualità nei processi di pm

Pubblico oggi un mio articolo uscito sulla rivista DeQualitate di Tecna Editrice, che aproffondisce i temi del miglioramento continuo della qualità nei processi di project management (La qualità nei processi di project management).

Statement of Work

Quanto è importante lo statement of work?

 

 

Wikipedia definisce così lo statement of work (SOW) .

Il PMBOK(r) definisce il SOW come una descrizione “narrata” del prodotto/servizio che il progetto dovrà realizzare e  che  solitamente dovrebbe contenere:

• le motivazioni di business che spingono l’azienda ad istanziare il progetto (strategia commerciale, adeguamenti legali, avanzamenti tecnologici, ecc.)
• decrizione dell’ambito del prodotto/servizio: verranno qui descritte le funzionalità, caratteristiche e gli attributi che il prodotto dovrà possedere, preferibilmente messe in relazione alle motivazioni di business sopra descritte
• piano strategico: gli obiettivi e i tempi che si vogliono perseguire attraverso la realizzazione del progetto

Il PMBOK(r) definisce inoltre che tale documento dovrebbe essere frutto di sforzi fatti internamente all’azienda.

Questo, dal mio punto di vista, è ovvio in quanto chi conosce le reali esigenze che ha l’azienda, quali le necessità da soddisfare e in quale modo, sono solo le persone interne all’azienda stessa.

Il documento compilato potrà quindi essere inoltrato ai fornitori in gara, per poter procedere alla compilazione dell’offerta.

La mia esperienza quotidiana, ahimé, mi dice che quanto sopra scritto non è sempre vero.

Spesso il cliente ci convoca quando ancora non sono definiti completamente strategia e caratteristiche del prodotto, ma semplicemente quando è nata un’idea che lui stesso non ha avuto ancora il tempo di sviluppare, se non in maniera generica.

Ed è proprio a questo punto che capita di incappare in una prima situazione di stallo.
Il cliente crede che la chiacchierata di qualche ora in cui ci ha spiegato per sommi capi cosa desidera, possa essere sufficiente a redigere un’accurata offerta.
Quando poi accenniamo, data la mancanza di dettaglio, alla necessità di esporre in fase di offerta la fatidica “forbice di prezzo” più o meno ampia a copertura dei rischi e delle incertezze date dal mancato dettaglio, nascono spesso le prime incomprensioni.

A quel punto per riappianare la situazione, sfoderiamo la carta della consulenza che noi, in quanto project manager, possiamo erogare al cliente per aiutarlo nella fase di prima analisi e  redazione  congiunta dell fatidico statement of work che servirà, quindi, anche alla redazione di un’offerta più mirata.

Ecco il secondo punto di stallo: il cliente, con fare piuttosto scocciato, ci chiederà “Perché mai ti dovrei pagare per permetterti di farmi un’offerta?”.

Il cliente raramente capisce che quel documento dovrebbe redarlo da solo.

Questo gli permetterebbe realmente di analizzare, capire in profondità, strutturare e dare risposte alle reali esigenze aziendali, creando condivisione tra le persone interne coinvolte e ponendo una prima importantissima pietra miliare per il successo del progetto.

Ecco, questo è lo scenario.
Ovviamente ogni regola esiste per essere smentita o per permettere alle eccezioni di manifestarsi, fiere e splendenti.
Ecco quindi, che nel giro di due settimane mi si sono presentate non una ma due eccezioni a quanto appena raccontato.

La prima riguarda la progettazione di un portale piuttosto corposo, rivolto ad un mercato relativamente nuovo, portale che richiede particolari attenzioni stilistiche, funzionali, navigazionali.

La seconda, diametralmente opposta, riguardante la creazione di un’applicazione aziendale volta ad automatizzare articolati processi di gestione del ciclo di vita dei prezzi di prodotti di una importante azienda multinazionale, in cui entrano in gioco meccanismi composti di approvazione delle richieste, di integrazione con sistemi pre-esistenti, vincoli stringenti di facilità d’uso, necessità avanzate di reporting e business intelligence.

Bene, per entrambi oltre alla richiesta di quotazione, ho ricevuto un dettagliato ed esaustivo statement of work.

In entrambe vengono descritte: la situazione di lavoro iniziale, le motivazioni per cui si vuole intraprendere quello sviluppo, le diverse funzionalità del prodotto, il tutto corredato da esempi mirati e particolareggiati, meccanismi di calcolo, modalità di approccio in funzione delle utenze previste.

Insomma un SOW come “disciplina comanda”.

Certamente quanto fatto dai pm delle due aziende li ha visti impegnati per parecchio tempo, nella revisione dei processi esistenti, in tentativi “infiniti” di coinvolgimento dei colleghi in diverse riunioni, nella redazione dei suddetti documenti e nel rendere partecipe il management.

Quanto fatto da loro, sicuramente permetterà all’azienda di meglio indirizzare i propri investimenti nel perseguire le strategie di business, ottenere quotazione mirate dai singoli fornitori e indirettamente aumentare le possibilità di successo del progetto, dovuta ad una generale maggiore chiarezza intorno ai requisiti di progetto.

Quindi non importa da che parte stiate: se siete il committente dedicate il tempo opportuno per la compilazione del SOW la vostra azienda se ne gioverà, se siete invece chi ha l’incarico di eseguire il progetto, insistete perché il SOW vi venga fornito.

European School of Project Management

Oggi è una giornata particolarmente felice perchè Diesys Informatica, azienda di cui sono presidente, è diventata socio sostenitore del consorzio ESPM (European School of Project Management).

 

La European School of Project Management è un consorzio senza fini di lucro che diffonde la cultura e la formazione per il governo e l’esecuzione dei progetti, cuore del cambiamento organizzativo per le imprese e le pubbliche amministrazioni.

L’interesse di Diesys Informatica a seguito dell’entrata nel consorzio, è di creare sinergia con lo stesso al fine di favorire una crescita delle entità coinvolte e del movimento di project management in generale, volendo cogliere al meglio le opportunità che il mercato offre in quell’area.

Siamo certi che mettendo a disposizione del consorzio la nostra professionalità, potremo cogliere l’occasione di una sicura crescita, anche e soprattutto professionale grazie alla collaborazione con i professionisti appartenenti al consorzio stesso.

Un ulteriore sforzo della nostra realtà nella direzione del networking tra aziende di alto valore; cammino già iniziato da diversi mesi, con la nascita del gruppo di imprese l’Albero Logico di cui siamo tra le entità fondatrici.