Misconceptions about Project Management and Project Managers

1.1. Project management is not only limited to schedule management, likewise, a project management plan is not only a schedule plan.

1.2. Agile Development is not just for software projects.

1.3. The principles and foundations of project management apply not only to projects, but also on an enterprise level, in product management and even in your career and personal life.

1.4. The following are not methodologies:

1.4.1. Project management is not a methodology.

1.4.2. The Project Management Body of Knowledge (PMBOK) guide is not a methodology.

1.4.3. Agile by itself is not a methodology.

1.5. Describing the PMBOK as being based on Best Practices.

1.5.1. Don't forget that the PMBOK is based on Good Practices.

1.6. The five Process Groups in the PMBOK 6th Edition and earlier are not "phases" or "stages", but rather they are groups of processes related to the ten Knowledge Areas.

1.7. When a project fails, blaming only the project manager.

1.7.1. If the project fails, there are many factors that lead to the failure of the project, perhaps beyond the management and control of the project manager.

1.8. Value creation from the project

1.8.1. Completion of a project based on the iron triangle (scope, cost, and time) does not mean the project is successful. If the project does not deliver value, it is considered a failed project.

1.8.2. One of the mistakes is considering scope, cost, and time as the only elements for measuring the success of the project, without paying attention to the value of the outputs, outcomes, results, and impact.

1.9. There is a significant difference between leadership in work teams which are able to manage themselves (Self-Organizing Team) and leadership in the manner of freedom and non-interference (Laissez faire).

2.1. Being certified as a PMP, PRINCE2, or by other programs does not imply that you are now a qualified project manager. The certificate is merely a supporting element; it won't ensure that you can manage projects professionally on its own.

2.1.1. Your professional or academic credentials will not be the only basis for employment with a company.

2.2. Just because you are proficient in using tools, programs, and project management software like Primavera, MS Project, MS EPM, JIRA, and so on, does not imply that you are an expert in project management.

2.2.1. While it is true that these skills are necessary and should be acquired, they are not the secret to solving the puzzles of complex projects.

2.3. While there are plenty of courses and adept trainers focused on instruction, excelling in training doesn't necessarily translate to proficiency in project management; someone might excel in delivering content or facilitating learning but not possess the skills of a seasoned project manager.

2.4. Learning leadership skills does not imply that you have become a leader.

2.5. Project manager doesn't equal general manager, even in project-based organizations. Micromanaging through central forces is a recipe for disaster.

2.5.1. Being a project manager grants you responsibility, not ultimate authority over the team. This holds true even in project-centric structures. Centralized control through task forces is a guaranteed path to failure.

2.5.2. the title of Project manager doesn't grant you the power to micromanage. This is true even in project-based setups. Trying to control every action through central task forces is a surefire way to derail your project.

2.5.3. Project manager? More like project babysitter. Don't get power-hungry, especially when the central task force leash is already on. Micromanagement is a recipe for project meltdown.

3.1. Dishonesty: A Recipe for Project Disaster

3.1.1. Cooking the Books: Falsifying client reports or progress updates might seem like a quick fix, but it paints an inaccurate picture and breeds mistrust. When the truth comes out, you'll be left scrambling to regain credibility.

3.1.2. Painting a Sunshine Picture: Glossing over challenges and roadblocks to appease the sponsor might feel like protecting them, but it deprives them of valuable information to make informed decisions.

Be upfront about risks and roadblocks, and work together to find solutions. 

3.1.3. Turning a Blind Eye to Supplier Shenanigans: Ignoring supplier delays or missed financial deadlines can snowball into bigger issues down the line.

Address concerns promptly and hold them accountable to contractual agreements.

3.1.4. Fearmongering the Team: Motivating your team by exaggerating the client's negativity or the project's bleak outlook is a dangerous tactic. It creates anxiety, erodes morale, and ultimately hinders performance.

Foster trust by being transparent and focusing on achievable goals.

Remember, honesty is not just the best policy; it's the only sustainable policy in project management. Be genuine, be upfront, and be accountable. Your project and your reputation will thank you for it.

3.2. Trying to change people.

3.2.1. You can't change people, but you can help them improve themselves by:

3.2.1.1. Inspiring them

3.2.1.2. Supporting them

3.2.1.3. Impacting them

3.2.1.4. Changing how you deal with them.

Trying to change people is like trying to herd cats. Inspire them, be their cheerleader, show them they matter, and be patient. They'll change when they're ready, not because you told them to.

3.3. Based on the article "Twenty Common Mistakes Made by New or Inexperienced Project Managers" by Harold Kerzner:

1. MISTAKE #1: Too Much Detail

2. MISTAKE #2: Pretending to Know More than You Actually Do

3. MISTAKE #3: Preparing an Ambitious Schedule

4. MISTAKE #4: Overreliance on Repeatable Processes

5. MISTAKE #5: Ignoring Problems

6. MISTAKE #6: Failing to Share Accountability with Functional Managers

7. MISTAKE #7: Gold-plating the Deliverables

8. MISTAKE #8: Failing to Understand What Stakeholders and Sponsors Want to Hear

9. MISTAKE #9: Not Fully Understanding Requirements

10. MISTAKE #10: Refusing to Ask for Help

11. MISTAKE #11: Ignoring Problem

12. MISTAKE #12: Believing in Saviors and Miracles

13. MISTAKE #13: Making Promises for Rewards

14. MISTAKE #14: Failing to See Dependencies between Projects

15. MISTAKE #15: Don’t Tell the Client They are Wrong

16. MISTAKE #16: Show Everyone Who’s the Boss

17. MISTAKE #17: Failing to Get to Know Your Team

18. MISTAKE #18: Failing to Insulate the Team from Politics

19. MISTAKE #19: Not Willing to Say “No”

20. MISTAKE #20: Selecting the Right Battlefield

3.4. In her book "Motivation: How to Increase Project Team Performance", Peterson represented some common motivational mistakes (Peterson, 2007, pp. 63-65):

1. “Whatever motivates me will motivate others.”

2. “People are motivated primarily by money.”

3. “Team members love to receive formal awards.”

4. “Give them a rally slogan.”

5. “The best project leader is a strong cheerleader.”

6. “These people are professionals. They don’t need motivating.”

7. “I’ll motivate them when there is a problem.”

8. “I’ll treat everyone the same. People like that, and it will be motivating for them.”

3.5. Failing to keep up with the latest trends.

3.6. Do everything yourself.

3.6.2. The project manager's primary function lies in orchestrating the various aspects of the project, ensuring their seamless integration. They are not a one-person show, handling every minute detail or delving into technical specifics. That's the domain of the task force and other departments, whose expertise complements the project manager's overarching vision. Together, they create a unified symphony of stakeholders, teams, plans, and measurements, all working in harmony to achieve optimal project performance.

3.7. The PMBOK is not a holy guide that you have to follow literally. It should be adapted to the organization's context for effective work development. If you're not willing to tailor processes, leave it to others.

3.8. When you start a project, you start with implementation and execution, without paying attention to your important role in the initiation, preparation and planning processes.

3.9. Wait until the project constraints are exceeded to escalate problems and inform stakeholders.

3.10. Inappropriate escalation.

3.11. Treat time, cost, or resource estimates as facts.

3.12. Assuming the week is five days and eight working hours.

3.12.1. Despite considering the Ideal Time assumption, particularly in non-Agile project scheduling, numerous project managers presume a standard workweek of five or six days, with eight-hour workdays. They plan projects based on these assumptions as if they were absolute. Unfortunately, I must convey that, under optimal conditions, the actual completion rate is only 75% of that time, equating to merely four working days.

3.13. Assigning tasks to team members who do not have sufficient experience to accomplish tasks on the critical path.

3.14. When estimating the time, not differentiating between the capabilities and competence of the different members.

3.15. Always "Padding" in estimating activities as a Contingency Reserve.

3.16. Confusion between the concept of "excellence" and "perfection" upon delivery

3.16.1. Perfection often disrupts and delays.

3.17. Assuming that delivery will be smooth from the first time.

3.18. Reliance on Checklists or previous risk registers when managing risks.

3.19. While embracing the values and principles of agile development involves welcoming change at any point, neglecting to address risks exposes your project to the threat of Scope Creep.

3.20. Delegating risk management to others. Don't forget that this is the responsibility of the project manager.

3.21. Making promises that cannot be kept.