Force Field Analysis: an Agile Version

Everytime we learn something new, a practice, a tool or a technique related to our working activity, we naturally try to understand how that knowledge can be ported into our environment. It happens, indeed, that the most challenging things, even if fascinating and powerful, are often discarded with a superficial statement “it will never work with us”.

Everyone of us do not want to change their habits, do not want to leave their “lovely” comfort-zone, we are accustomed to it, it is familiar.
Even if we know that the old way of doing things doesn’t work anymore and we must change it, we want to approach to it smoothly, gradually, it would be better, indeed, if someone else will do it for us.

This happens every time to people that come from a traditional project management environment who are called to face the new agile discipline: most of the time they know very well the benefits of it, what kind of improvement it can bring and furthermore they know that agile is, above all, about changing their mindsets, their habits.

Initially, they make the error of thinking that agile is primarily a matter of using the right techniques and tools; they start to ask about which tool is better to manage the product backlog, which other tool can be used to write and decompose the user stories or, yet, what tool can be used to manage the task board in an electronic way.

Even in these cases, don’t give up!

Continue to explain the value of managing the user stories with index cards (face-to-face communication, direct negotiation, establishing a sense of trust with the customer), furthermore, that attaching and moving the tasks directly on the taskboard, during the daily meeting, is a ceremony, a moment where the team continue to learn about the project, the product, the other team members.
And, again, go on stressing the fact that the product backlog grooming activity is an important one, which must be done together with the product owner: directly, face-to-face.
What is paramount, in my opinion, is that the team and the other stakeholders, should really and honestly understand that agile is mainly a matter of collaboration and short-feedback and that is better to avoid the use of any remote and asynchronous communication tool, except for particular situations (distributed teams, maybe?).

When they realize that doing agile means, primarily, to change theirselves and how they did things so far, lot of doubts raise and even the better, the more detailed and the more honest explanation, is not able to convice them 100%,

That could be the time to use the Force Field Analysis tool, with some little adjustments to make it funnier.

First of all I ask a representative of the team, better if s/he is the most skeptical, to come at the whiteboard.
Then I ask the whole team to think at the agile transition as a journey, navigating the sea by boat (representing SCRUM) where the team is represented by the sail.
Actually what I ask to the member, is to draw the sea, the boat, the sail and to write on the hull of the boat the name of the agile discipline and on the sail the the name of the team.

Now it’s time for the team to elicit what advantages, benefits, strengths, agile embodies, which they can bring to their workplace, identifying them as the airstreams blowing into the sail, able to push the boat from the start to the finish-line.
These air flows shall be written and drawn on the top left area of the whiteboard (sky).

Then, I ask them to list the drawbacks and the weaknesses of implementing agile in their organization.
These are the contrary forces that work under the hull of the boat as marine drifts; those must be reported on the right bottom area of the whiteboard (sea).

Having this information written on the whiteboard, in front of them, help primarily to find any new advantage or drawback not already written but, more important, allow the team to compare the two groups and really understand how to cope with them.

The final part of the “game” is, to think how to exploit any single strength (opportunity) and for each drawback how to smooth, adjust, avoid or even accept it (risk), in order to let the boat reach the new land of agile where better results are awaiting for them.

Someone could ask: why cannot continue the old way of representing the force field analysis? The one that uses the tabular representation of it?
An explanation is that using metaphores (the journey, the sea, the boat, etc.) help people to better explain their feelings, abstracting from the reality and finally helps the brain in the process of memorization of concepts, emotions and ideas.

Be the the new year, an inspiring one! (AJRX49CFX279)

Conducting the user requirements gathering interview

Do you know how to conduct that kind of interviews having success?

The most important rule is: forget about your technocratic vocabulary.
One of the most cited complaints from the users towards the IT staff is:

“I do not understand a word. Too many acronyms and tehcnical words.
When I’ve asked for explanations it seems they were so annoyed!“

With that in mind, prepare yourself to the interview, by studying as much as possible about the business domain the product will be applied.
Analyze the business processess, the input and output data.

Gather information from internet, look for any competitors’ solutions/products already existing. Talk with any experts in your company trying to better understand the logics of that area.
Compile a glossary containing any jargon, abbreviations and acronyms.

Ok, let’s move on the next step.

Arrange the meeting following these rules.

The meeting shouldn’t lasts more than one hour, the attention will drop down inexorably after that time.
Take into account an extra time of fifteen minutes before and after the interview, for collateral activities such as email sending, phone calls, etc.
Keep the last 10 minutes of the interview for a Q&A session.

Create the agenda of the meeting and send to the participant at least the day before.
The meeting shall be take place neither in your office, nor in the one of the interviewee, otherwise too many distractions will occur and, furthermore, the interviewee or you will not be confident to completely openly speak.

Now it’s time to proceed with the interview.
Create a calm environment.

Remember that you must instaurate an environment in which the comunication should freely flow: expose clearly the objectives of the meeting and what are your expectations. Be assertive and remember that your first goal is to listen and not to speak.

In general, try to pose short and simple questions: no hyperbole,
the technicalities are banned!
The questions itself should not influence the answers:

“Isn’t true that the application will be used only by the accountant users?”

but rather

“What kind of users will use the application?”

Remeber, during this phase you must remain concentrated on the problems: do not yet think about the solutions.
The user wants to be heard, s/he wants to be sure that you understood his/her problems.

Start asking general questions: your goal in this initial phase is to obtain as much information as possible,
posing fewer questions.
Avoid any questions to which is possible to answer with a yes or a no.

• What are the main necessities?
• To what problems is necessary to find solutions?
• What happens today that should be changed in your working enviroment?

When the overall scenario is well delineated and understood, pass to the second step by gathering detailed information about the most important points: what is unclear to you, what is more complex, what are the processes and data involved (probe questions).

During this phase try to catch any nuances, redundant concepts, any special emphasis in what the interlocutor is saying, because those things bring quality to the message.
Be aware also of any dissonances you feel, because it is a trigger that something is not clear or that you don’t agree with.

A well-structured process in conducting an interview should be:

• General questions
• Probe questions
• Explore any open points
• Gather data and examples
• Find an agreement by repeating the main points

Finally, during the interview, try using the same words, acronyms or abbreviations the interviewee uses.
Reflect his/her posture, gesture and voice tone, you should be well tuned with him/her.
Rephrase what s/he has said, giving and obtaining feedback.
Some healthy NPL never hurts, isn’t it?!

The SWOT: an innovative tool for agile retrospective

Yes, of course I’m joking, the SWOT analysis isn’t an innovative tool, but have you ever use it for analysing how an iteration has gone?

Hi there, holidays are over and a new working year is ready to start!
During my vacations I read a lot about agile retrospectives and it was an opportunity to compare the techniques and the tools mentioned in those books, with the ones I use in my everyday working life.

What actually I did not found is one of my preferred tool: the SWOT analysis.
That tecnique is so versatile that can be adapted easily. It was born to be used mostly for conducting marketing activities to devise new products.
On the other side, that of the traditional project management approach, it was applied to the projects in order to conduct the risk identification phase.

Actually, I use that technique at least in two other occasions.

Firstly, when I want to stimulate and accompanying the growth process mine and of my colleagues and team members. I help them to identify, related to their job and daily working activities, what are their strenghts and weaknesses in order to understand which opportunities could be developed and to what weaknesses they are exposed to.
Secondly, it is a fantastic tool to conduct a retrospective meeting. How? Let’s go!

As the major part of you already know, an agile retroscpective meeting is a meeting that usually lasts 4 hours, which is held at the end of a sprint (iteration), just immediately after the team has shown what it was developed (demo meeting).

The scope of this meeting is to reflect about what was good and what was bad about the last iteration. Considering the necessity to help people to actively participate and freely express opinions, ideas and any doubts, it’s better (read as mandatory) if that meeting is opened only to the the team, the scrum master, and the product owner (but only as a spectator).

Once the environment is ok and the meeting is open, distribute to the participants the SWOT matrix template and ask to each to address their thoughts on the iteration just concluded.
The focus is on the tools and techniques used, the approaches and behaviours kept by the people involved, the things happened during the iteration.
It is mandatory to absolutely avoid any direct reference to collegues, rather indicate the behaviour that should be rewarded or penalized, never cite an individual.
Remember that it is not a matter of finding the guilty, it’s a matter of improve performance and why not, to work better with sustainable paces.

Compile

The first quadrant contains the strenghts: which attitudes, behaviours, approaches were good. What, in the end, shall be reiterated to actually continuing to bring real worth to the project.

The second quadrant is a container of weaknesses (please do not confuse it as a garbage bin, there’s much to learn from our weaknesses): think of what has gone in the wrong way and analyze what is missing and where the problems were.
Think about the bad effect that was caused by the problem and try to conduct an analysis in order to climb to the root reason.

Now it’s time to concentrate on what could be exploited and what should be avoided: respectively the opportunities and threats quadrants.
The opportunities quadrant should comprise a list of “good things/objectives” the team/project/sprint could reach in case of investing in improving the strengths or bridging the weaknesses above reported. If possible connect each opportunities or threats to the relative strenght or weakness.

On the contrary the threats quadrant is reserved to the consequences that could arise in case no improvement is put in place.

Arrange

When every team member has finished to compile the “SWOT”, it’s time for each of them to write on a white-board, flip-charts or sticky notes both the strengths (good things) and weaknesses (bad things) giving insights regarding the opportunities and threats that they can bring aboard.

When finished, the agile retrospective leader (role that should be assigned in rotation to every team member), tries to identify which items are duplicate, eliminate them and  the remaining are grouped, clustering them under a category, a word, a statement that clearly explains them.
Now you have a well arranged situation of what has been the iteration just finished, in terms of good and bad things: solicit the team to devise and propose activities that aim to solve problems and enhance the performance according to what above reported.

Vote

And, finally, it’s time to vote: do you know DotVoting?
Simply assign a predefined number of votes to each team member that he can distribute on the activities.
Everyone can assign one vote for each desired item or assign all the dots/votes to one item, if they feel that is an important one.

Arrange the result as a bar graph (do you remember pareto and the 80/20 rule?) and pick the most voted activities, those must be executed during the course of the next sprint.

Final Considerations

• Do not put into the pipeline too many activities for the next iteration; most of the time it is better to process one at a time.
• Try to focus on the strenghts instead of weaknesses.
  Try to maximize the benefits coming from what the people can do better: their talents and qualities.
  It is more difficult to work on weaknesses.
  Obviously, if the weakness has an heavy and bad impact on the team/project/sprint, do not hesitate to deal with it.
• Everyone during the meeting should actively participate: your responsibility as a Scrum Master is to go along with the retrospective leader and stimulate who is not actively participating or try to contain who tends to speak to much or has a coercitive approach.
• Keep in mind these three words: APDC, CPI, Kaizen. They teach us to continue to improve the process, even a small adjustment can lead to great improvements.

The big elephant in the room

“Elephant in the room” is an English metaphorical idiom for an obvious truth that is being ignored or goes unaddressed. The idiomatic expression also applies to an obvious problem or risk no one wants to discuss. It is based on the idea that an elephant in a room would be impossible to overlook; thus, people in the room who pretend the elephant is not there have chosen to avoid dealing with the looming big issue. (Wikipedia)

During the last weeks I have given some training sessions regarding project management topics (gathering user stories, planning, estimating, communicating, etc.). What I did, and in some cases what was explicitly asked for by the clients, was to speak about those topics from a traditional point of view as well as the agile one (Might I lose the opportunity to talk about agile?!).

Well, the courses were done for big organizations such as banks, assurances and a multinational that produces energy and it happened that when we have finished to analyze the two different approaches, it was clear to all the attendees that in some situations (telling the truth the most of them) the agile approach in planning, estimating, communicating and conducting the project, would be definitively the best one.

Indeed, some of the attendees exasperated by the problems they encountered, said that they already have tried to embrace agility, changing their approach in estimating activities, trying to be more adaptable in managing the changes and fostering the collaboration between all the parties involved in the project, but, systematically, they had to give up, due to problems and frictions with other colleagues.

People, most of the times, don’t want to change.

They do not want to change approaches, mental schemas, “habits”, because this implies:

• an effort that they don’t want to pay
• they do not want to leave their “lovely” comfort zone
• they have fear to loose power or control

Surprisingly, this happens even if it is clear to all that they have big problems in managing projects, even if they know they cannot face to projects’ changes smoothly, even if they know they cannot be more productive, faster and cannot improve the overall quality of their products, without a change.

They pretend not to see, the big elephant they have in front of them, which is staring at them, a bit embarrassed, trying not to move too much.

That problem is even more bigger, if the people who deny the existence of such an elephant, are the managers, the bosses, the decision makers.
The employees, after some trials in convincing them, could give up, surrendering to such a strong resistance.

This situation is a catastrophe for each of the parties.
The employees stop working assertively.
The boss looses the esteem of his/her colleagues and a great opportunity to improve the overall performances.
And, finally, the whole company, soon or later, will lose the most talented people, because for sure, they will not accept for a long time, such a frustrating situation: instead of being considered worthwhile “change agents”, the company treats them as annoying people.

PNL e Project Management 2^ Puntata

Sono diverse le occasioni in cui, come project manager, potremmo essere chiamati a parlare in pubblico.

Indipendentemente dal numero di persone che ci troveremo di fronte, dovremo essere preparati, efficaci nel modo di comunicare. Perché non farci aiutare da qualche tecnica? Il sistema 4MAT per esempio!

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.

PNL e Project Management

Siete buoni comunicatori?  Comunicate in maniera efficace?
Come ve la cavate quando dovete negoziare risorse, budget o tempi di progetto?
E quando dovete presentare trend e risultati al management?

Le capacità di un buon comunicatore sono spesso innate: hanno molto a che fare con la sensibilità personale e la percezione di noi stessi e del contesto in cui ci muoviamo.

Fortunatamente la programmazione neuro linguistica ci aiuta ad allenarle: ne gioverà sicuramente il nostro progetto ma trarremo vantaggi anche nella vita di tutti i giorni.

Per essere buoni comunicatori bisogna innanzitutto sentirsi a proprio agio nel contesto in cui ci troviamo, essere ben predisposti e utilizzare un linguaggio e un approccio positivo.

Dobbiamo in ogni momento essere consapevoli del fatto che ognuno di noi ha un proprio modello del mondo derivato dalle sue esperienze, pensieri e propensioni.

Tenerlo in considerazione e adattare il nostro modello di comunicazione è un vantaggio: l’interlocutore sarà automaticamente (inconsciamente) ben disposto ad ascoltarvi dato che parlate la sua “stessa lingua”.

Il modello che ognuno di noi si è creato è possibile riconscerlo da tre fattori: linguaggio, uso della voce, fisiologia.

A tal proposito la PNL descrive quattro principali sistemi rappresentazionali:

• Auditivo
• Visivo
• Cinestetico
• Auditivo Digitale

Sistema Auditivo

La persona che ha questo come modello di riferimento, dà molta importanza ai suoni: li apprezza, li sa riconoscere, spesso le senzazioni e i ricordi sono legati a suoni specifici, riconoscono facilmente i diversi dialetti.

Rimangono ammaliati dal suono delle cose: a loro piace ascoltare musica, parole, racconti; danno molta importanza al suono della voce, al timbro, al volume, al ritmo, alla velocità con cui si susseguono le parole.

Se il nostro interlocutore predilige questo sistema, dobbiamo dare enfasi nei nostri discorsi a parole che richiamino suoni, utilizzare in maniera particolareggiata la voce, accentuare le pause, utilizzare correttamente il timbro della voce per effettuare sottolineature.

Sistema Visivo

Queste persone ragionano per immagini, spesso i loro movimenti mentre parlano sono veloci, repentini, quasi a scatti.

Se fate loro delle domande che implicano un ragionamento spesso li vedrete guardare leggermente in alto, comunicheranno molto velocemente perché le immagini nella loro mente scorrono e loro le devono rincorrere per potervele raccontare.

Quando parliamo con essi dobbiamo prestare attenzione all’utilizzo di parole che evochino immagini, le possiamo descrivere con minuzia e la nostra comunicazione dovrebbe essere incalzante, con un buon ritmo, un tono di voce piuttosto alto, dobbiamo produrre nella loro mente una sequenza di fotogrammi che facilmente interpreteranno e memorizzeranno.

Sistema Cinestetico

Queste persone danno molta importanza alle sensazioni, hanno un rapporto molto intimo con esse e riescono a descriverle in maniera particolareggiata.  A loro piace molto toccare le cose, annusare gli odori, osservare.

Hanno un ritmo della parlata più lento, con un timbro di voce spesso basso e profondo, si sà, le emozioni vengono dalla “pancia” ed è da lì che le devono andare a riprenderle.

Con queste persone comunichiamo con sensazioni, emozioni, metafore particolarmente evocative.

Non occore parlare velocemente e dobbiamo farlo con un ritmo sicuro, ma con voce calma e che contempli pause per dare loro il tempo di “digerire” il messaggio che stiamo comunicando.

Sistema Auditivo Digitale

Queste persone sono molto pratiche.

Ragionano per dati, logica, numeri, processi. Analizzano, comparano e trovano soluzioni.

Vogliono dati oggettivi su cui impiantare ragionamenti per deduzione (proprietà transitiva) che cercano poi di smontare attraverso negazioni o eccezioni.

Valutano razionalmente implicazioni e sono in grado di correlare facilmente le informazioni.

La nostra comunicazione dovrà essere orientata alla concretezza e praticità. Le nostre presentazioni dovranno prediligere grafici, tabelle, comparazioni. Dovremo fornire le motivazioni, dimostrarle attraverso dati e numeri, fornire subito eventuali eccezioni e spiegare come saremo in grado di gestirle.

Li riconoscerete dal fatto che vi staranno ascoltando guardando inensamente voi e i dati che avete sottoposto, tenendo le braccia conserte, oppure con una mano sotto il gomito e l’altra a reggersi il mento, valutando ogni singola parola, ritti sulla spina dorsale.

Ma cosa fare se stiamo parlando a più persone?

Come faccio a capire a quale sistema appartengono?

E anche se riuscissi a riconoscerlo, come potrei parlare loro contemporaneamente in tutti gli stili sopra descritti?

Beh, sicuramente non è semplice.

Certo conoscere la platea a cui ci stiamo rivolgendo è importante. Potremmo per esempio scegliere quali sono gli stakeholder più importanti per la nostra presentazione e utilizzare soprattuto il loro sistema rappresentazionale.

Ma spesso ci troviamo di fronte a persone che non conosciamo cosi a fondo e allora potremmo usare lo schema:

K -> A -> V

Questo schema ci suggerisce di iniziare la nostra presentazione utilizzando il sistema cinestetico, passare all’auditivo e finalmente terminare con il visivo.

Perché?

La prima regola è di non commettere l’errore di partire con il visivo, saremmo troppo veloci, incalzanti, in qualche modo dissonanti per gli altri sistemi, soprattuto il cinestetico.

Partire con quest’ultimo infatti permette di conquistare sin da subito quello più “lento” e in qualche modo più complesso in quanto bisognoso dei propri tempi di reazione.

Una volta conquistata la fiducia di queste persone, saranno quindi ben disposte a seguirci quando cambieremo lo stile in auditivo.

Questo stile fa un uso molto incisivo del senso dell’udito e anche i cinestetici lo apprezzeranno perché spesso le sensazioni sono facilmente associabili ai suoni.

E i visivi?

I visivi saranno abbastanza annoiati. (

Si chiederanno perché siete così lenti ad arrivare alle conclusioni, perché il vostro tono della voce è cosi basso.

E perché mai fate tutte quelle pause?

Ma proprio quando si staranno chiedendo se hanno fatto bene a presenziare al meeting in corso, ecco che voi cambierete ancora registro e comincerete ad incalzare il pubblico.

Il vostro racconto si animerà e comincerete a legare necessità, obiettivi, trend e risultati del progetto, a immagini vivide, capaci di conquistare anche loro, e anche in poco tempo. Ricordate? Loro sono persone veloci!

Ah, un ultima cosa: nel vostro viaggio attraverso i tre sistemi, non dimenticate di fornire anche qualche dato, numero, grafico, descrivete con precisione i processi coinvolti nelle decisioni.

In caso contrario rieschiereste di perdervi per strada gli auditivo-digitali!

Alla prossima e…non cambiate canale, sono in arrivo nuove puntate sull’argomento!

Be good!

Planning a kick-off meeting

Un buon kick-off è garanzia di successo del progetto?

Un paio di giorni fà, ho condotto presso un cliente il kick-off di un nuovo progetto.

Progetto non particolarmente complesso nei suoi requisiti, che però nasconde diverse insidie in quanto obbliga un’interazione e integrazione molto forti con i sistemi del cliente, vede coinvolti diversi stakeholder, alcuni dei quali fuori dall’Italia e che, infine,  impone un adattamento a standard procedurali e di documentazione in uso presso il cliente.

La fase analitica inziale che ha dato vita alle stime e all’offerta, non è stata particolarmente dettagliata; diversi erano quindi i punti aperti e i dubbi circa alcune implementazioni.

Il kick-off sarebbe stato quindi momento fondamentale per cercare di chiarire al meglio quanto era ancora sfumato, privo di contorni nitidi.

Ho voluto affrontare il tema facendo uso di una mappa mentale in cui potessi raccogliere tutte, e dico proprio tutte, le tematiche che sarei andato a discutere nel meeting.

La prima cosa che ho fatto, è stata quella di fare una review completa di tutta la documentazione a mia disposizione suddividendo le tematiche nelle seguenti categorie:

• Open Points, in cui ho raccolto tutte le questioni non ancora chiare alle quali si sarebbe dovuto dare risposta nel kick-off
• Functionalities, categoria nella quale ho raccolto tutte le funzionalità del prodotto, implementando rami gerarchici a raggruppare funzionalità dello stesso tipo, in stile WBS
• References, tutti i documenti di riferimento (allegati alla mappa) che hanno dato luogo alla formalizzazione del plan di progetto
• Systems Involved, i diversi sistemi (hardware e software) esterni coinvolti, con i quali l’applicazione dovrà dialogare
• Application Roles, i diversi ruoli applicativi con relativi permessi
• Stakeholders, le persone coinvolte direttamente o indirettamente dal progetto
• Risks, la categoria che raccoglieva una prima analisi dei rischi

Grazie a questa prima iterazione, la mappa ha cominciato a prendere corpo.

Con l’aiuto di un membro del team che si occuperà dello sviluppo, si è proceduto alla scomposizione delle funzionalità in attività; questo ha permesso di delineare la WBS (allegata in formato excel alla mappa) e sulla quale è stato possibile procedere con stime di dettaglio (primo riscontro della mia stima draft fatta in fase di offerta).

Al kick-off ci siamo voluti presentare subito con i layout di esempio delle pagine dell’applicazione, per permettere a tutti di discuterle e di trovare da  subito condivisione sulle interfacce e sulla loro navigabilità.

Anche questa presentazione è stata allegata alla mappa.

Un altro passo è stato organizzare le funzionalità in deliverable del prodotto.

Questo punto è stato ispirato dalla metodologia agile:

• rilasci frequenti e temporalmente vicini
• inclusione già primi rilasci delle funzionalità più importanti (customer business value)

Sono state quindi identificate 4 deliverable, a rilasci distanziati di circa due settimane lavorative l’una dall’altra, includendo le funzionalità più importanti nelle prime due.

Quest’ultimo punto permetterà di:

• innalzare subito l’attenzione del cliente perché in grado di verificare subito le funzionalità più importanti
• garantirci una maggiore “probabilità” di feedback sulle deliverable
• fugare sin da subito dubbi o malintesi sulle funzionalità più importanti invece di scoprirlo alla fine con conseguenze dannosissime

Ho,infine, aggiunto:

• una categoria “Legenda” che riportava le descrizioni delle diverse icone o simboli grafici presenti
• una categoria “Agenda” che riassumeva i macro-punti che sarebbero stati discussi nel meeting
• Una categoria “Attendees” che elencava i partecipanti al kick-off

Il kick-off è andato benone.
Ho potuto mostrare la nostra idea di implementazione del progetto e raccogliere diversi suggerimenti, correzioni, aggiustamenti da parte del cliente.

I punti nella categoria “Open Point” sono stati tutti completamente evasi ed hanno ricevuto le risposte attese.

Gli stessi, a fronte delle risposte, sono stati inclusi nella categoria “Decisions”.

E’ stata prevista un’ulteriore categoria “Action Points” in cui sono state aggiunte le azioni immediate che si sarebbero dovute svolgere e a carico di chi.

Infine sono state aggiunte alcune segnalazioni nella categoria “Risks”.

La mia mappa alla fine conta le seguenti categorie:

• Legenda
• Agenda
• Attendees
• References
• Functionalities
• Stakeholders
• Systems Involved
• Applications Roles
• WBS
• Draft Layouts
• Deliverables
• Decisions (prima chiamata Open Points)
• Action Points
• Risks

Ora non mi rimane che utilizzare una delle funzionalità di cui sono più innamorato di MindJet MindManager: l’esportazione in word. Questo permetterà la redazione della meeting minutes in pochi minuti, la spedizione agli altri partecipante del kick-off e finalmente….possiamo cominciare a lavorare.

Un buon kick-off non garantisce certo la riuscita del progetto, ma sicuramente siamo riusciti a creare commitment, responsabilità e chiarezza su cosa e come dovrà essere fatto il lavoro e chi e quando dovrà essere svolto.

Commitment e responsabilità

Nel post corrente parleremo di due temi sui quali si arenano parecchi progetti e sono la responsabilità e l’impegno rispetto a qualisiasi attività di progetto.

Il tema della responsabilità sui task di progetto viene spesso sottovalutato.

Quando si pensa al termine attività di progetto si crede che queste siano delle occupazioni a carico del solo project team, mentre il concetto di task di progetto deve essere espanso  a tutte quelle attività di esecuzione, certo, ma anche di recupero delle informazioni, risoluzione di problemi o punti aperti, attività di networking tra gli stakeholder o di promozione del progetto stesso.

Insomma, qualsiasi azione che porti ad un avanzamento incessante del progetto verso la meta.

L’esperienza mi insegna che nella maggior parte dei casi le attività di esecuzione dal team sono quelle con una effettiva alta probabilità di esecuzione nei tempi prestabiliti.

Al contrario, le altre attività spesso in carico agli altri stakeholders, sono sistematicamente sottovalutate. Peggio ancora, vengono ripetutatemente istanziate e reiterate nei meeting che si susseguno durante il ciclo di vita del progetto, annotate come open points nelle relative meeting minutes e poi regolarmente disattese.

Affianco al concetto di responsabilità di un task, troviamo il concetto di commitment.

Ho cercato la traduzione esatta del termine in diversi dizionari e ho trovato le seguenti traduzioni: impegno, dedizione, promessa, affidamento, coinvolgimento; tutti hanno molto a che fare con la parola fiducia.

Prendersi in carico qualcosa e permettere agli altri interlocutori di affidarsi a noi. Un vero e proprio vincolo tra le persone in cui ci si impegna a portare a termine un’attività.

Il commitment ha molto a che fare quindi con la sfera “emozionale” legata anche all’entusiamo che si viene a creare all’interno degli stakeholders di progetto nel portarlo a termine; entusiasmo messo a rischio quando il progetto incontra i primi ostacoli che l fanno ritardare o bloccare.

Le figure di project manager e sponsor in questi casi sono vitali e importantissime.

Il primo ha il dovere di monitorare constantemente lo svolgimento delle attività, la raccolta delle informazioni e il clima che caratterizza il progetto e le persone coinvolte.

Deve rivitalizzare l’interesse quando è in calo, rivedere le assegnazioni, richiedere solleciti feedback, porre le persone incaricate di fronte alle responsabilità di eventuali ritardi sulle loro attività.

Dall’altra parte, proprio per non eccedere in facili entusiasmi, deve cercare di regolamentare l’eccesso di entusiasmo facendo rimanere molto focalizzate le persone sulle loro attività, rimandando qualsiasi festeggiamento o entusiamo al momento dell’effettivo raggiungimento del singolo obiettivo.

Lo sponsor è vitale nell’alimentare continuamente l’interesse, che calerà di sicuo nei mesi a venire, nei confronti del management e degli utenti aziendali chiave coinvolti.

Parallelamente ad un lavoro incessante di comunicazione, per questi scopi viene i aiuto la RACI matrix.

Esistono altri due sinonimi RAM (Responsibility Assignment Matrix) o LRC (Linear Responsibility Chart) che fondamentalmente riconducono allo stesso strumento.

RACI Matrix. Fonte PMBOK 3rd Edition

• Responsible, indica a chi è in carico il task per la sua esecuzione; è la persona che è responsabile del suo completamento
• Accountable, termine che si sovrappone al precedente perchè indica sempre una responsabilità ma questa è sicuramente più forte della precedente. Potremmo riassumerla con questo esempio: un task è stato delegato da una persona ad un’altra. Chi ha preso la delega del task è il responsabile e chi l’ha fornita è in ultima analisi il vero e ultimo responsabile (accountable). Il project manager, per intenderci,  è l’unico vero accountable del progetto; il successo o il fallimento dello stesso ricadrà, in ultima analisi, sulle sue spalle
• Consult, la persona indicata da questo attributo deve essere assolutamente consultata durante l’attivazione, l’esecuzione e la fine del task in oggetto
• Inform, vincolo molto più leggero rispetto al precedente. Indica che deve avvenire un’azione di inormazione verso la persona indicata in quel task

 Spesso quando si ha a che fare con questi strumenti si effettua l’errore, io in prima linea, di sottovalutarne la forza: tutto sommato è solo una matrice che dice chi deve fare che cosa!

Invece la formalizzazione delle decisioni prese in termini di responsabilità e commitment e la sua ufficializzazione attraverso tali strumenti e un vincolo forte di fronte a tutti gli stakeholders di progetto.

Ricordate? Ha molto a che fare con la fiducia!

E, in una aggregato sociale o comunità, la comunità di progetto appunto, la fiducia è uno dei valori più importanti.

Comunicazione agile

In questo post cercheremo di valutare come rendere agile la comunicazione all’interno del progetto.

Come già discusso in altri post precedenti, la comunicazione è colonna portante dell’intera disciplina del project management.

Si sa, il 90% del tempo di un project manager è occupato da problematiche inerenti la comunicazione: riunioni, documenti, telefonate; tutte queste occasioni sono direttamente proporzionali al numero degli stakeholders coinvolti.

Anche il rapido aumento della complessità dei progetti stessi è un fattore che complica non poco la faccenda: l’insorgere di problemi legati a cambi di specifiche, accorciamento nei tempi, revisioni al ribasso di budget, bilanciamento delle aspettative dei numerosi stakeholders che hanno spesso interessi contrastanti, obbliga il project manager ad esercitarsi giornalmente attraverso la negoziazione e il compromesso.

Infine, al suo interno deve saper interpretare due differenti ruoli con stili comunicativi piuttosto differenti: quello del leader che, fissata la meta, deve saper coinvolgere e motivare il team al suo raggiungimento e quello del manager in grado di gestire budget, costi, contratti, diagrammi e gantt.

E allora come fare?
Personalmente ho tratto suggerimenti sia dal PMBOK sia da alcuni libri che parlano di agile project management e che trattano in dettaglio il tema della comunicazione.

Disponibilità informazioni

Innanzitutto dobbiamo rendere disponibili le informazioni a tutto il team e dobbiamo fare in modo che queste siano facilmente raggiungibili.

Dotiamoci quindi di un sistema di gestione documentale, o simile, che sia in grado di centralizzare le informazioni, indicizzarle per chiavi e renderle disponibili ai team dei singoli progetti senza troppe limitazioni o complicazioni nel poterne fruire, pena il fallimento dell’operazione.

Mezzi

Distribuite negli uffici una serie di lavagne, di pennarelli e cancellini, utilizzabili da tutti ed in qualsiasi momento per chiarire concetti, annotare appunti, liste, flussi di lavoro.

Dotate tutti i pc del team di un’applicazione di instant messaging tipo skype, msn, icq: alcune domande o questioni possono essere risolte in chat senza dovervi alzare o interrompere ciò che state facendo.

Se avete questioni urgenti o importanti da discutere e la persona con la quale dovete parlare non è nella vostra stessa stanza, alzate il telefono e chiamatela; non aspettate di incontrarla, non scrivete email se non siete certi di riuscire a chiarire a dovere la cosa: impieghereste di sicuro più tempo a scriverla che a spiegarla direttamente  a voce.

Infine, per tutto il resto, utilizzate le email ma fate buon uso delle notifiche di consegna e lettura se la questione è particolarmente importante ed imparate a taggare le email più importanti, cosi da poter eseguire azioni di follow-up nei giorni successivi qualora tardino ad arrivare delle risposte.

Modalità

Una delle prime regole della comunicazione agile parla di comunicazione Face-to-Face.

Parlate direttamente alle persone. La comunicazione faccia a faccia è la più funzionale e offre diversi vantaggi:

• Comunicazione sincrona, permette di capire immediatamente se il nostro messaggio è stato recepito correttamente
• Non dobbiamo aspettare per avere risposte alle nostre domande: le avremo subito e subito potremo verificare se le abbiamo percepite correttamente
• Potremo captare anche i messaggi non verbali; quei messaggi cioè fatti di postura del corpo, tono della voce, sguardo, movimenti delle mani, che caratterizzeranno ancor di più il messaggio ricevuto

Contenete il numero di membri del team. Team troppo grossi potrebbero essere dispersivi, aperti a maggiori problemi di conflitti e terra fertile di malintesi.

Collocate nello stesso ufficio (war-room) tutti gli appartenenti al team, questo agevolerà non poco le comunicazioni, permettendo ad ognuno di usufruire della presenza dell’altro istantaneamente: un consiglio, un chiarimento, un suggerimento arriveranno subito.

Portate, almeno una volta alla settimana nella war-room con il vostro team, un rappresentate del cliente.

Fate in modo che il cliente accetti di far partecipare ai lavori una persona esperta dei processi di business che state implementando; nel caso invece che l’esperienza di tale persona non sia approfondita in quel campo, lasciatela nei suoi uffici, porterebbe solo dispersione e poca concretezza.

Se dovete parlare con l’estero prediligete una video conference call.

Parlare in lingua straniera senza poter vedere l’interlocutore è un supplizio: difetti di pronuncia, rumori di fondo della linea, impossibilità di aiutarsi con la lettura del labiale, oltre che della mancanza dei già citati nessaggi non verbali, sarebbero un ostacolo alla corretta comprensione di quanto detto durante il meeting.

Governo delle comunicazioni

Limitate i canali di  comunicazione.

Guardate questa formula: n * (n-1) / 2 >> canali bidirezionali.

Dove n è il numero di stakeholder del progetto. Significa che se in un progetto avete identificato 10 persone coinvolte, vuole dire che ipoteticamente vi saranno 45 canali di comunicazione bidirezionali che si possono apripre tra i vari stakeholders.

Semplificate!

I membri del team parlano esternamente attraverso la voce del project manager o attraverso uno solo, il più anziano solitamente, dei suoi membri.

Siate voi, in quanto pm, i principali interlocutori e quando si scende troppo in dettagli delegate ad un membro del project management team (uno dei vostri assistenti) che vi farà un riassunto corredato da meeting minutes.

Limitate l’entropia: cercate sempre la sintensi in voi e nei vostri interlocutori, puntate alla concretezza e al pragmatico: l’eccesso di dettaglio non è mai un bene.

Infine, se il troppo commitment verso il progetto sembra aver reso troppo teso l’ambiente, organizzate un bella pizzata: anche questo serve al vostro progetto…ricordate le parole “team building”?