Top 5 Myths in Project Management

You don’t know what you don’t know”. I have often heard many people ranging from top executives, business managers to the guy at the lowest cadre say different things about project management.

Some of the times, I have been at the center of those discussions. There are two major reasons for these submissions. Either ignorance or wickedness, with huge data supporting the former. To this end, I have compiled, in my opinion, the top 5 Myths in Project Management


There is a disturbing statistic that underscores this myth. You often find managers and top executives arbitrarily assign the role of a Project Manager to just anybody in an organization. The belief is, there is really nothing technical in Project Management. To disprove this myth, let us first look at what Project Management is. According to PMI, arguably the most respected and universally accepted authority is the field, as documented in the PMBoK Guide, Project Management is the application of Skills, knowledge, tools, techniques to project activities to deliver the objective of the project or meet the project requirements. Putting that in perspective, to be able to manage projects, an underlining requirement is that one must possess the skills, knowledge, tools, and techniques for managing projects, and a second requirement is the application of those skills, knowledge, tools, and techniques. Remember a fool with a tool is still a FOOL. If you are not trained in project management, if you do not have the knowledge, skills, if you can’t use the tools and techniques, you have no business managing projects. In fact, the word Project Manager is the most abused lately


Very few topics stir argument every time I facilitate training or Speak at conferences on Project Management. One constant trigger is when I say “A Project Manager is not expected to be a Technical Person”. I understand that it does help a great deal if the Project Manager has some knowledge of the technical space in which the project falls into, but this is not a requirement at all. This is why there are SMEs on projects and the project manager constantly meets with and seeks advice from them. Remember the technique called “Expert Judgement?”
Matter of fact, there is the tendency to become too granular in the technicality of a Project if the Project Manager has detailed technical knowledge of the project. Effective Project Management thrives on communication, documentation and interpersonal skills, and these skills are not the forte of technical people.



Unfortunately, this myth comes not only from executives and business managers but also team members. When this category of people fails at the first argument, they tend to shift ground and say Documentation can be done later, but the truth is “LATER NEVER HAPPENS”. Once the final product is approved by the client and signed off, the team is immediately reassigned to another project. The Agile Manifesto, which some have used as the main excuse, never said Documentation is not important. It simply says “working software over comprehensive documentation” and at the end, Agile Manifesto says “while there is value in Comprehensive documentation, we value working software more”. Two points I would like to stress in the manifesto. 1: The manifesto never said documentation, it only says comprehensive documentation and that it very correct. Depending on the nature, size, complexity or the environment of the project, some projects do not require comprehensive documentation but rather minimal documentation. But there must be documentation. 2: The manifesto never said there is no value in comprehensive documentation, it only says there is more value in getting the product out.

Documentation is boring, it is tiring, it is difficult. But just like insurance, it is better to have it and not need it than to need it and not have it.

So, to correct this myth, understand the documentation requirement of the project and give it the required amount


Often, people ask me which is better between agile and the traditional waterfall. My response has always been, both methodologies have their own strength and weakness. The normal practice has historically been that the client explains what he or she wants and magically disappears till deliverable due date simply because he has other commitment and has employed you as a Project Manager to take care of the attention and other details. Yet this same client wants you to adopt Agile. Interaction and Collaboration between the team and the user community (client) are the backbones of Agile Methodology. Understanding the requirement of the project will determine which methodology to adopt. There is no bad or good methodology. Instead, we have an appropriate and inappropriate methodology.


Edwin Thorndike defined Hallo Effect as the cognitive in which an observer’s overall impression of a person, company, brand, or product influences the observer’s feelings and thoughts about that entity’s character or properties. While this has been somewhat valuable to Marketing, adopting such in Project Management, where someone who has done very well in their technical field is assigned to be Project Manager, has been constantly discouraged. This is very common in corporate organizations.

These are the Myths I could come up with. Constant education will help address these myths and correct them.

In your opinion, what are the top myths in Project Management