I vari modi per avere successo, parte 2 - un caso reale

[^X^]

Ciao a tutti,
siccome ho dovuto preparare un case study reale per un corso di Team Leadership, ho pensato di proporvelo - per una volta quindi niente spippolamenti teorici.
E' in inglese, e non ho nessuna intenzione di tradurlo; sinceramente se qualcuno non riesce a leggere il mio pessimo inglese non credo che avrebbe comunque la possibilità di capirne il contenuto una volta tradotto.
Essendo piu' che altro una traccia da discutere in classe, non sono sicuro che sia esaustivo... ma sono pronto a rispondere alle vostre domande 

Conflict and Communication 1 – a project management changeover

Scenario:
The project XXX started as an internal project in 2006, with great enthusiasm and commitment that decreased over the time leaving the project in an undefined status (no resources clearly assigned to it, no realistic deadlines, no cost/budget control, and no clear information available to the management). The assigned project manager, after having set up the technical design, had received other major priorities and in 2008 he had no time to follow it. In May 2008, the Steering Committee assigned me the Project Management role, asking me to "coordinate the last and decisive Oracle intervention -10 days- in order to finalize an already up and running system".

Analysis of the situation:
It was immediately clear that the management and the Team over evaluated the project status, and that the 10 days would have been just the beginning. As a PM, I decided that the situation was nobody's fault and it was due to a lack of committed guidance and mising planning/estimation/communication. The problem was obviously an indirect and hidden conflict of interests between the Development Team and IT Management, in which the Project Manager had a very difficult intermediate position.

* I was quite new at YYY, without a history of previous successful tasks (so I couldn't really use any authoritative behaviour)
* The Development Team was very little motivated by the lack of business interest and not able to justify with real deliverables the money and time spent on the project. They had done a very good design/prototype job that had value – but they were not able to show it. An additional issue was that they were not shielded from the continuous external environmental changes (fluid requirements, no business process definition)
* The previous project manager (still important part of the team because of his skills and historical memory) was originally asked to design a general and global architecture, so he had good reasons to defend it against project rescoping that in my view were absolutely necessary in order not to have the project cancelled
* The IT Management anxiety was due mainly to the lack of project control (sliding deadlines, no convincing artifacts, no planning)
* I had to communicate the project bad situation transparently to IT Management without causing the immediate project cancellation and without discredit my colleagues job.

The main challenge in this set of conflicts was winning the trust of a skeptical team (that saw the change of project manager as a sort of punishment for the previous one) and of an even more skeptical management.

Solution:
* After a deep technical assessment, I reduced the original project scope to something that we could have delivered in less that 6 months, with many intermediate deadlines with visible deliverables; then I communicated the situation transparently to the Steering Committee, highlighting the massive but invisible work already done and trying to be credible for the future promises as much as possible. Doing that, I reduced the distance between the Team (who started feeling appreciated) and the Management (who started seeing a light out of the tunnel)

* In order to win the Team resistance to rescoping, I had to create and maintain two different planning: the long period one (to show that the global vision was consistent to the original architecture), and the short period one (to achieve visible and immediate results)

* I maintained a consistent approach over the months, firmly refusing every change request arriving from a "confused" business side. Inside the team, I tried to eliminate unmanageable situations (ex: a very part time external business analyst) and to empower the most motivated members. After some months of consistent behavior I finally saw the Team and Management motivation rising dramatically, so the project really started having some future.

Recap of key points:
* When a situation looks like a complex interaction of general and personal conflicts, it is important to identify all of them, to eliminate interdependencies and to face/resolve all of them one by one

* Some conflicts are real, many others are less obvious and sometimes hidden (and the people involved generally are not even aware of them). It is very important to understand why the various components are in conflict and eliminate the root cause as soon as possible (simply imposing a no-conflict situation doesn't really work)

* My approach was a combination of the typical 5 styles (Confronting, Avoiding, Collaborating, Adjusting and Compromising). My personal preference is usually Collaborating (high interest for both my own and others concerns); I rarely use Confronting (high interest in my concerns and low in others') and Compromising (that looks to me a way not to face any conflict and problem)

[JBGrenouille]

Facciamo che lo salvo e lo leggo piu' tardi...

[^X^]

Intanto ne ho preparato un secondo

Conflict and Communication 2 – project ZZZ

Scenario:
At the beginning of 2008, I was requested to coordinate an external intervention in order to guarantee the delivery of an urgent version of ZZZ; the project manager was not from IT at that time, so subsequently IT asked and obtained from the Steering Committee the official project guidance.

Analysis of the situation:
* the business project manager was in conflict with the IT coordinator (the technical guy who coordinated the development made by an external company with the internal resources deployment and configuration work); the first was blaming IT (officially during Steering Committee Meetings) for not delivering in time, the second was reacting defensively pointing out that the PM was continuosly changing the requirements – promising new features without consulting him in advance
* I, as the new Project Manager, immediately entered in conflict with the IT coordinator; he had the strong convinction that he should have been appointed to the role instead of me, because of his past work and commitment to the project. His position was probably a little exagerated but I took seriously his point. He was collaborative, but not happy in having me as manager: the typical result was having a team member that did what requested, but not much more – in other words not proactive. We started wasting a lot of hours in endless discussions about very unimportant issues

Solution:
* After many investigative discussions with him, I realised that his position "I am ok, you are not ok" was not limited to this project assignement, but was a more generally negative life view (and so much more difficult to eradicate or circumvent). Many logical discussions went nowhere, and any attempt on persuading him in not being so paranoid and conspiracy oriented was largely unsuccessful. The more I tried to put his shoes and understand his point of view, the more I realised how deep –but not real- was his discomfort.
* Using a terminology learned only later (during the Team Leadership training – Transactional Analysis), I understood that a mature and cooperative (adult-adult) communication was not possible – almost not without a huge and costly amount of hours of discussion. After some weeks, I decided to move to a "parent/child" style, a more authoritative behaviour in which I stopped trying to explain my choices in order to involve him and I started to microplan every single task without justifying it and refusing to start discussions not related to the technical activities. It worked from a professional point of view (the project finally delivered), but I regret that my approach was a failure from the personal and human side.

[james.mar]

figooooooooooooooo!

I love project management and I've just started a PM course here in Sweden..........awesomeeeee!!!


per quanto riguarda il primo progetto, penso che le chiavi di volta siano state l'uso di milestones (si erano smarriti focus e motivazione, erano pertanto necessarie scadenze a breve termine per sfruttare l'inerzia e il momentum derivanti dal loro achievement), e la trasparenza.

grande ^X^.


The excited about PM, james

[SunBeam]

E X comincia a fa i soldi...
Domanda: come si passa dall'IT al poject managment? Cosa che tutti vogliono fare ovviamente

[^X^]

per quanto riguarda il primo progetto, penso che le chiavi di volta siano state l'uso di milestones (si erano smarriti focus e motivazione, erano pertanto necessarie scadenze a breve termine per sfruttare l'inerzia e il momentum derivanti dal loro achievement), e la trasparenza.

Hai capito perfettamente! E' proprio cosi'. Tieni presente che io non ho mai fatto corsi (o meglio, li ho fatti a posteriori), quindi tutto deriva da esperienza e dalla passione che ho di analizzare e leggere le situazioni (e questa ce l'ho anche grazie a voi).

[^X^]

Domanda: come si passa dall'IT al poject managment? Cosa che tutti vogliono fare ovviamente

Inizio rispondendoti con una battuta seria. Siccome tutti sgomitano per fare i project manager (perchè pensano solo ai benefici del ruolo), generalmente vengo scelto io perchè a me... non frega un accidente pur avendo evidentemente le doti necessarie. Si impone un parallelo molto forte con la seduzione...

Dire IT e project management è comunque troppo generale. Vediamo se riesco a sintetizzare il mio pensiero.

Passaggio da un ruolo tecnico (programmatore, sistemista) ad un ruolo di project management tecnico
Questa è l'evoluzione generalmente preferita dagli appassionati di tecnologia, anche se dal mio punto di vista non è particolarmente vantaggiosa perchè è sostanzialmente un vicolo cieco: chi sbaglia strada rimane intrappolato.
Comunque sia, occorre sforzarsi di avere una cosiddetta visione ad elicottero: capacità di passare dalla visione di dettaglio alla visione di insieme continuamente; le persone intorno a te le devi motivare facendoti riconoscere competenza tecnica e dando il buon esempio. Attenzione ai rapporti con gli altri manager, che vedono il pm tecnico come qualcosa di "bizzarro"

Passaggio da un ruolo tecnico ad un ruolo di project management globale
Questo è un percorso a mio avviso piu' interessante, ma occorre procedere per step successivi perchè quasi nessun manager crede a questa possibile evoluzione da parte di un tecnico.
Innanzitutto bisogna progressivamente spostarsi verso l'utente finale (per esempio da programmatore ad analista tecnico, poi analista funzionale, infine analista di processo); una volta che si è a contatto con l'utente finale, è piu' facile iniziare a capire come ragiona e a comportarsi in modo da ottenere la fiducia del lato business in generale. Questo passaggio intermedio richiede un'enorme capacità di mediazione per non perdere la fondamentale capacità di essere stimati e rispettati in ambito tecnico (conosco mille casi di cogliocelli bocconiani che pretendevano di iniziare dall'analisi di processo, e che poi venivano giustamente boicottati dagli implementatori tra mille sberleffi).
Una volta completata la transizione, occorre pero' davvero delegare il lavoro tecnico, fidandosi del proprio team e trattenendosi dalla tentazione di ficcare il naso ovunque...

[The Legend]

molto interessante, grazie X, è da assimilare con calma per un novizio almeno

[-eFFe-]

complimenti! 
Vorrei dei chiarimenti sul rapporto "padre/figlio" che hai tenuto nel secondo caso, qualche esempio insomma.

Il mio percorso e' proprio quello che descrivi: da tecnico, a PM tecnico.
Purtroppo e' ancora un percorso a meta' perche' imposto dalla situazione dell'azienda (non cercato da me quindi), con scarsa preparazione, e con confusione di ruoli (sono in parte ancora progettista, e allo stesso tempo PM anche di me stesso ).

Risultato: un bagno di sangue

La pianificazione e' approssimativa (nessuno me l'ha insegnata), le attivita' di gestione PM mi costano enorme tempo e fatica che tolgono risorse alle attivita' tecniche stesse (per buona parte svolte da me medesimo): in pratica l'avanzamento sulla carta viene fatto troppo spesso ma le attivita' reali progrediscono poco e niente, col risultato che siamo in ritardo, le milestones slittano e i costi aumentano 

E siccome non vendiamo piani ma prodotti (ci pagano per quelli), ritengo che tutta questa sovrapianificazione sia un'emerita st*onzata (suicida peraltro).

[SunBeam]

Grazie caro, e +1.
Comq l'è dura, non riesco a immaginare neanche da dove iniziare io che ti ricordo faccio gestione sistemi.