Every time I start one of my courses or workshops the one thing I make clear to all participants is that there is no silver bullet to managing projects. Like driving a car, one needs to practice. Before jumping into a detailed analysis of PM taking as a reference the PMBOK® Guide I start by saying that there is a lot of common sense that needs to be applied as a way to soften-up the norm.
I have found that applying common sense – which is the least common of all senses – one can help PM practitioners get a better grasp on the ideas behind PMI® excellent framework. As I address process groups, knowledge areas or ITTOs, I try to stick to basics concepts. So here are some ideas:
- You do not put your time or money without thinking on what are your expectations from that decision. There is always an opportunity cost to be analysed. A project does not get started without having a business case expressed with clearly defined variables and values (metrics). On the product side (output) it clearly states the stakeholder´s benefits or expectations (stability, reliability). On the project side (outcome) the business value it will generate (ROI, PBP, NPV).
- There are no plans to be made if the project goal is not defined, even if the goal (output) is not crystal-clear (i.e. R&D). Appropriate strategies will be made once you know what you are aiming for. Defining the PM Life Cycle is a good starting point. Is linear, incremental, iterative, adaptive or extreme PMLC the best way to manage this endeavour?
- There is always a shortest, least expensive and/or highest benefit alternative to develop the project. So do not start your project without generating alternative solutions to reach the goal taking into account the associated constraints. Some call it Front End Loading or Fuzzy Front End. Take some time exploring these alternatives. The project strategy and plan just does not fall out of heaven.
- If there is no sense on start the house construction without having all design drawings and required permits, there is no reason to work on subsidiary plans if there is no WBS defined. This PM deliverable helps the team get a better grip of the work to be done, provide better estimates to develop the project management plan and it serves a clear way to align team member´s effort to the project objective.
- It is unreasonable to think that project funds are waiting to be withdrawned from the bank. Remember that project financing sources, cost of financing and a well planned project income from deliverables is indispensable. Scheduling deliverable´s sign-off is a good basis for cashflow planning.
- Product quality is not only technical specs or acceptance criteria. What is the benefit we are looking for the project output? Is it efficiency, reliability, maintainability and how is it that each subcomponent or work package is providing or adding value to that desired output? I have found that the Quality Function Deployment technique as a starting point to understand product definition based on client´s expectations (VOC).
- Its nice to talk about qualitative or quantitative risk analysis. Yes, the probability/impact matrix, Monte Carlo or @risk come handy on an PMP Certification course but what about when you go back to work or your boss demands from you a sound quantitative analysis? It is not just a matter of tools and techniques. There is a need to understand that this probability estimation is based on historical data and this is not something that you will easily find. A good starting point is to identify what are the most important metrics required (time, cost, quality, resources, etc.) and if not available start generating reliable data to work with in future projects.
Last but not least I decided to write this post in English because if we are to see ourselves performing in a globalized world it makes common sense for PMs go beyond PMIsms required to pass the PMP Exam. I have found that ENG has come very handy when I had to deal with virtualized project teams, system users or suppliers from US, India, South Korea, Russia and China.