{"id":7661,"date":"2024-06-19T14:19:40","date_gmt":"2024-06-19T14:19:40","guid":{"rendered":"https:\/\/plaky.com\/blog\/?p=7661"},"modified":"2026-03-05T12:00:27","modified_gmt":"2026-03-05T12:00:27","slug":"project-management-myths","status":"publish","type":"post","link":"https:\/\/plaky.com\/blog\/project-management-myths\/","title":{"rendered":"Debunking 7 Common Project Management Myths"},"content":{"rendered":"\n

\u201cThe road to hell is paved with good intentions.\u201d<\/em><\/p>\n\n\n\n

It\u2019s worth remembering this phrase when you get a piece of advice. Most advice is well-meaning, but sometimes, it\u2019s just way off base.<\/p>\n\n\n\n

It\u2019s not uncommon for wrong advice to get repeated so often that it becomes a myth \u2014 something that\u2019s taken for granted.<\/p>\n\n\n\n

In this text, I\u2019ll go over some of the more common project management myths that you should be aware of and avoid. I\u2019ll also mention when these myths should be followed since some of them can be correct in the right context.<\/p>\n\n\n\n

To start with, let\u2019s take a common myth that is used outside of project management as frequently as it is used in project management.<\/p>\n\n\n

\n
\"Project<\/figure>\n<\/div>\n\n\n

Myth #1: The customer is always right<\/h2>\n\n\n\n

Imagine you\u2019re a doctor. A patient comes to you and says: \u201cHey, doc, I need you to prescribe me this and this medicine. I should take it 3 times a day for 7 days and avoid physical activity. If I get a high fever, I should also take this pill, but no more than twice per day.<\/em>\u201d<\/p>\n\n\n\n

Sounds ridiculous, doesn\u2019t it? You\u2019re the doctor, but the patient already \u201cknows\u201d <\/em>exactly what their diagnosis is and how to treat it.<\/p>\n\n\n\n

Well, that\u2019s often what user feedback for developing projects looks like. The users and customers don\u2019t just come to you with their issues. They also (strongly) suggest how to fix them, because, of course they do.<\/p>\n\n\n\n

Just like the patient isn\u2019t a doctor, and therefore doesn\u2019t have the medical knowledge needed to gather the right data and interpret it properly (i.e., which blood tests to take and how to decipher their results), the customer isn\u2019t a project leader with access to project data.<\/p>\n\n\n\n

The truth: Listen for symptoms and not for solutions<\/h3>\n\n\n\n

You should<\/em> listen to your customers. <\/p>\n\n\n\n

In project management, they can \u2014 and will \u2014 shine a light on problems that need fixing. <\/p>\n\n\n\n

Just don\u2019t blindly implement their solutions, because they are likely to not fix the issue or cause other issues<\/strong>.<\/p>\n\n\n\n

For example, in Fortnite, shotguns used to be by far the best weapon. The players were shouting at the top of their lungs at the developers to reduce the damage it did, and so the devs listened and did just that. It didn\u2019t make any difference.<\/p>\n\n\n\n

Then they analyzed the situation and realized that the problem wasn\u2019t the shotgun damage. It was that the building mechanic forced all encounters to happen in close quarters, where the shotgun shined. <\/p>\n\n\n\n

So, they made building resources more scarce and explosive weapons that can destroy buildings more plentiful. This meant that battles could be waged over longer distances, which meant the shotgun was no longer the best weapon in the game. Problem fixed.<\/p>\n\n\n\n

In conclusion, the customer is always right when they provide descriptive feedback (how your product makes them feel and why), but their prescriptive feedback (how you should fix the issue) should be taken with a grain of salt.<\/p>\n\n\n\n

\n

\ud83d\udca1 Plaky Pro Tip<\/strong><\/p>\n\n\n\n

Are you looking to streamline your game development project pipelines and increase transparency? Then it\u2019s high time you started using a project management tool:<\/p>\n\n\n\n