Cu toată viteza în zid. Despre managementul de proiect

Una din sesiunile mai puțin tehnice ale conferinței de săptămâna trecută a fost despre project management: probleme și soluții. Mi-am luat notițe și a rezultat o listă destul de consistentă - nimic revoluționar, majoritatea punctelor sunt de bun simț, însă utile, pentru că în practică, indiferent de domeniu, există situații când orgoliul, lipsa de comunicare sau atitudinea pasiv-agresivă n-au cele mai bune efecte asupra lucrului în echipă.

Deși lista se adresează mai ales proiectelor IT (merge mână în mână cu conceptele AGILE și SCRUM), miezul ei este universal. Personal, cred că o să-mi folosească. Discuția s-a purtat în germană, mi-am notat impromptu, în engleză, ideile principale, n-am să le mai traduc, dar dacă găsiți neclarități sau greșeli vă rog să-mi ziceți.  

Target:

• define clearly the target, so that you can compare completion against it (definition of done);
• make sure the target is understood, make the team members repeat it with their own words;
• start formally the project, so everybody knows it has started. Celebrate when the project ends.

Team:

• a group of people with an idea is not a team;
• "I am the most important/nothing works without me" problem. Solution: the team has to decide who does what;
• "I am the most qualified to do that, but I have no time" problem. Solution: delegate to somebody else, so the project can move forward, trust the teammates;
• the solutions to the above two issues will also help if somebody leaves the team - at least two people have to have a deep understanding of any given part of the project and each team member should have a broad understanding of all the parts;
• problem when two people think they are the alpha male. Solution: the team had to decide who is the alpha male/project manager - he has the final word;
• "xyz is an idiot" problem, the project doesn't move forward, he will see that he's treated as an idiot. Solution: you have to modify your attitude;
• each project member has to have the courage to tell when a milestone is red or the project has hit a "wall", disregarding concerns about the next salary increase;
• complicated problems can be resolved by an individual/ complex problems by teams;
• IT guys need to understand what they're working on, to feel useful. Explain the reason behind the requirements;
• have a flexible mindset and a flexible architecture, don't be strongly opinionated;
• our job is to facilitate the business, not to try cool new stuff.

Work method:

• 70% of it projects fail because of soft problems (bad communication);
• "like the last time": everybody knows already most of what he has to do;
• make sure everybody knows to whom they have to talk to, define the standard communication method. Define clear decision paths;
• everybody has to know where/what is stored (documentation, requirements);
• "the lightbulb must really want to change" - work agile, spare energy: don't make agile transition under pressure, but promote it from the beginning;
• don't debate the tools, focus on content;
• "hidden hierarchy" problem: define roles and responsabilities, don't let persons from outside decide or put pressure on targets/features;
• a meeting has to end with the following results: what we have found and who does the work;
• divide the tasks, reduce the number of dependencies;
• blame and blind fate problem ("I told you so from the beginning" and "if x says so, we do it"). Think what could have we done differently.
• define what happens post-launch, don't ignore maintenance modus.