Debunking 7 Common Project Management Myths

“The road to hell is paved with good intentions.”

It’s worth remembering this phrase when you get a piece of advice. Most advice is well-meaning, but sometimes, it’s just way off base.

It’s not uncommon for wrong advice to get repeated so often that it becomes a myth — something that’s taken for granted.

In this text, I’ll go over some of the more common project management myths that you should be aware of and avoid. I’ll also mention when these myths should be followed since some of them can be correct in the right context.

To start with, let’s take a common myth that is used outside of project management as frequently as it is used in project management.

Myth #1: The customer is always right

Imagine you’re a doctor. A patient comes to you and says: “Hey, 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.”

Sounds ridiculous, doesn’t it? You’re the doctor, but the patient already “knows” exactly what their diagnosis is and how to treat it.

Well, that’s often what user feedback for developing projects looks like. The users and customers don’t just come to you with their issues. They also (strongly) suggest how to fix them, because, of course they do.

Just like the patient isn’t a doctor, and therefore doesn’t 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’t a project leader with access to project data.

The truth: Listen for symptoms and not for solutions

You should listen to your customers. 

In project management, they can — and will — shine a light on problems that need fixing. 

Just don’t blindly implement their solutions, because they are likely to not fix the issue or cause other issues.

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’t make any difference.

Then they analyzed the situation and realized that the problem wasn’t the shotgun damage. It was that the building mechanic forced all encounters to happen in close quarters, where the shotgun shined. 

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.

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.

Myth #2: Project managers don’t need technical skills

Occasionally, you’ll hear people say — with certainty — that project managers don’t need technical skills. “They’re just paper pushers,” or “It’s enough that they can communicate and coordinate effectively.”

In other words, they don’t need to know much or anything about the industry in which they are working — they only need soft skills.

Now it just so happens that a lot of my close friends are software developers, so I sometimes listen to them go on technical rants. 

And let me tell you something — I can barely follow what they’re saying. Some things I’ve sort of developed a basic understanding for, but many others just fly right over my head.

The truth: Without technical skills, you won’t even be able to communicate

Project managers who don’t have a solid grasp of the ins and outs of their industry, competitors, or even just the technical jargon used within it, will have a difficult time understanding how to orchestrate everything.

I wouldn’t be able to lead a software development project with my friends. No matter how good my leadership, negotiation, and other soft skills were, I would not be able to “communicate and coordinate effectively” with them when, half the time, I wouldn’t understand what they were saying.

In this sense, technical skills are a prerequisite for using soft skills to manage projects.

This problem extends beyond project management and can be applied to many general middle-management positions occupied by inept people who did not rise through the ranks and don’t understand how a job is done. A lot of people have had to suffer under these conditions.

This isn’t to say that a project manager on a software development project should be the top software developer expert in the team. The point is just that some technical skill is very much required to stay on top of the project and move it along.

Myth #3: Project managers only care about completing the project on time and budget

When looking at project success statistics, you’ll often find these three metrics highlighted:

• % of projects completed on time,
• % of projects completed within budget, and
• % of projects that delivered the promised scope (quality).

However, many discussions on what project managers should focus on mention only time and budget. “Which is more important, time or budget,” is a frequently asked question, with quality left as an afterthought.

Is there a scenario in which a project manager should only worry about the time and budget? 

Perhaps, if we’re talking about a project run by a large organization that has a product manager to worry about quality and features prioritization, as well as a program manager to ensure alignment with the organization’s strategic goals. 

Throw in some PMO support, maybe a change manager as well, and you’ll be left with a project manager who’s in a position to only worry about delivering the project output on time and within budget.

But most project managers won’t ever find themselves in this scenario. 

The truth: Most project managers wear many hats

According to project management statistics, 70% of all project teams are made up of 10 or fewer people. Most projects aren’t run by mega-corporations. 

So the average project manager has to wear many hats — they are also the product manager, the change manager, and often even the program manager (59% of PMs manage 2 to 5 projects at the same time). 

All of this is to say that most project managers very much have to care about the quality of the project.

While some project launches are time-sensitive and cannot be postponed — like anything holiday-related needing to be ready in time for the holiday in question — most projects depend on quality more than they do on deadlines.

Myth #4: You should stick to just one methodology

A friend of mine who’s a proponent of the “always use one methodology” mindset once compared project management methodologies to screw guns and screwdrivers. 

The screw gun was Kanban, which his team had been using and which had been working perfectly fine. 

Scrum, which their new manager insisted they switch to, was the screwdriver — a much less efficient tool for solving the same issue. 

According to him, everyone’s productivity went down after this transition.

Now, whether or not Scrum was the real cause of problems there, I do not know. It may well have been a “don’t fix it if it ain’t broke” situation. 

Lots of people take issue with Scrum — to my entertainment since their displeasure has inspired me to create a bunch of Scrum memes. But the screwdriver vs screw gun analogy doesn’t make sense because it implies that all methodologies serve the same goal — turning screws.

This isn’t the right way to think about it. Construction projects, game development projects, and marketing projects all have different requirements. So, instead of using one and the same methodology for all of them, it’s better to use the methodology that best fits the project.

The truth: Different methodologies cater to different kinds of projects

You shouldn’t think of project management methodologies and frameworks as more or less powerful tools used for the same goal. 

Instead, it’s better to think of methodologies as completely different tools used for different goals.

For example, Waterfall is great for construction projects and not that great for software development, while the opposite is true of Agile. 

If your workflow doesn’t include strict deadlines, then Kanban is great. And you can always use some form of hybrid methodology tailor-made for your workflow.

So, when does it make sense to use only one methodology?

Companies that run a lot of similar projects do stand to benefit from standardizing processes on a company-wide level. Even then, you shouldn’t blindly stick to one methodology as an ironclad rule — a single approach won’t necessarily fit all departments working on the project equally well.

Myth #5: Agile doesn’t require documentation

Documentation is annoying to gather and update, I get it. 

Agile’s lighter approach to documentation is certainly appealing when compared to documentation-heavy methodologies like Waterfall.

After all, Agile was developed as an alternative to Waterfall for software development projects. 

With Waterfall, the team would try to work out all the kinks before even writing any lines of code and had difficulty making revisions. This rigid structure makes sense — and is necessary — for construction projects, where you can’t simply replace the foundation once you build the walls. 

Software development is more flexible and allows you to make changes on the go, so why bog yourself down with boring documentation, right? 

Not exactly.

The truth: Agile projects require some documentation

This myth comes to us courtesy of the Agile Manifesto, which states: 

“Working software over comprehensive documentation.” 

The key word here is “comprehensive”. What this actually means is that documentation should not stand in the way of actual development. 

Or, as Agile practitioners like to put it, it should be JBGE (just barely good enough).

Myth #6: Execution is everything

“Execution is everything,” is the kind of statement that’s technically correct, but that often gets taken the wrong way or used to justify bad behavior.

Why bother making a detailed plan when things can always fall apart? What matters is how you perform when executing the project, right?

Wrong!

As the British Army eloquently put it: “Proper planning and preparation prevents piss poor performance.” 

The truth: Failing to plan is planning to fail

“Execution is everything,” should serve as a reminder that no matter how good a plan you have, it will fall through if you fail to execute it properly. 

When running a marathon, there’s always a chance you’ll twist your ankle. In this case, all your preparation (training, stretching, nutrition, equipment, etc.) won’t help you continue. But not preparing properly will not make you any more likely to cross the finish line.

So don’t take this quote as an excuse to do sloppy planning and preparation (or none at all). 

Failing to plan is planning to fail! 

If you do so, your success or failure will depend on luck more so than on your skill to execute the project.

Myth #7: Project management software is too expensive

A lot of new businesses start off unprofitable and so they avoid all extra expenses. Among these extra expenses, we also have project management software.

But is PM software really too expensive?

Sure it is — if you want your 10-person team to use an enterprise solution with loads of features they’re never going to need. But this isn’t the only kind of PM software out there.

Not only are there excellent affordable options to choose from, but some even offer free plans that cover everything a small team needs to get started.

The truth: Project management software is an investment that pays for itself

Take Plaky, for example. Its free plan supports unlimited users, boards, and projects. No essential feature is locked behind a paywall, so you can scale processes as you grow your business without worrying about exponentially growing costs. 

Granted, not all PM tools are like this. Some limit their free and low-cost plans to just a couple of users or projects. But we shouldn’t say the whole market is rotten just because of a few bad apples. 

Project management software is an investment that pays dividends and you can start benefiting from it at no cost.