For marketers
who love technology
Home » , , , » Top-5 real world project management lessons

Top-5 real world project management lessons

Project Management Lifecycle
Managing projects is a very valuable skill. I have worked 5 years as a project manager, interacting with technical and business people ranging from technicians to directors of forbes-global-2000 companies. I can share practice-oriented tips that will help you become a far better project manager.

1- The most common mistake in the history of project management!

Starting working on deliverables before having defined in details the project description is the most common mistake in the history of project management. From my experience in the corporate world, about 80% of project manager do this stupid mistake!

Why is it a very bad idea ? How could you possibly make useful progress if you have not defined the targets of the project? How could you avoid useless conflicts or standby periods if you have not agreed on the roles and responsibilities and identify the resources allocated to the project ? Believe me: starting earlier to work on deliverables before the project setup has been validated by all stakeholders results more often in additional delays than in earlier achievements.

2- The second most common mistake in the history of PM

It is a very bad idea to commit on deliverables:
- that you cannot provide or,
- that do not depend on you or,
- with a deadline / budget that you cannot achieve.

3- Choose your battles carefully: conflict often does more harm than good

Young project managers and even more experienced ones often create conflict when it is not required and even when it is harmful without bringing any benefit. Classical examples from real life:
  • Opposing the project to another initiative. That's stupid, because it means that your project is poorly defined and you are eating in the plate of another PM. You should redefine the scope of your project and have it validated by sponsors / hierarchy / the other project stakeholders to guarantee that everyone will be credited for one's work. 
  • Opposing to the stakeholders: you should try to convince the stakeholders if you disagree with them. But you should also have enough humility to admit when you are wrong or to follow the rule of the majority (and hierarchy) if you do not manage to convince them that you are right.
  • Opposing to the project members: sometimes people have personal constraints and they cannot do the work. Do not humiliate them. Do not blame them before you understand their personal situation. Discuss with them privately before anything. Be fair and direct. If there is no impact on the project, let it go. You are not a vigilant in charge of making justice: you are are project manager in charge of delivering results. So, do not seek responsibilities if it is not in the interest of the project. Rather seek for solutions, work around, and ways to prevent the problem to occur again.
4- Learn from theory and from practice

Project management is a domain where one can always progress. The reason for that is project management is above all "human management". It's not machines who work for the project, it's mainly humans.
  1. So, for the theory, read the PMBOK and train. Read psychology books, learn to decrypt body language.
  2. And on the practical side, learn to overcome your timidity to speak sincerely with project members, learn to say "no", learn to take your responsibility when you screw up (and you will, because PM is a difficult role and sometimes you just cannot succeed because of external factors)...
5- Beware of politics and shark-teethed colleagues
In my experience, I have often had to deal with people who did not want to work, but wanted to take credit for the success of my projects. As the saying goes "shit happens". So, how to deal with that kind of people? Like vampires, these long-teethed colleagues fear light. Thus, Transparency is the key word! If they do something you do not like, communicate frankly with your boss, along the following lines, and based on facts only:
  • The cause of the discussion: "He did this."
  • Why you need to solve the issue: "I do not accept that, because I consider it is harmful for the project. And based on my experience, the clear definition of role and responsibilities, with a single leader per project, is a key success or failure factor for projects. I also think that I am a legitimate leader for this project based on my skills and experience."
  • Your position: "That being said, I am ready to bear the responsibility of the project as long as I am clearly in charge or to step out if you think this colleague is more appropriate for that project. I only ask for a public clarification: am I the leader or not. As this person wants to be in charge, I do not think he will want to contribute to the project if I am confirmed in this role. This point should also be clarified."
Although some things can only be learned through experience, I strongly advise you to read the PMBOK to start with a good background in project management.


About Gilles


Post a Comment