5 Project Management Fallacies | Solutions that NEVER Work

I’m going to start with a summary! Here are the 5 decisions made in traditional projects that NEVER work: 

1. Adding more developers to the project to increase the velocity. 
2. Adding a buffer to the estimated timelines to cover the risks. 
3. Assigning all work items in advance to specific people. 
4. Splitting people’s time between multiple projects. 
5. Always reporting the watermelon status. 

Whether you agree or disagree, I’ll tell you why these “solutions” don’t work and what to do instead. 

But who am I to have an opinion on this topic?

Well, let me give you some context. 

I’ve been working in different industries, companies of different sizes, in different countries, with people coming from all over the world… 

I’ve seen the scenarios I’m going to share play out every time exactly the same way, and with the same exact results. 

I have a master’s degree in Project Management, and honesty, they taught us to do everything I’m gonna talk about.

So I get it. 

However, in the end, it’s just insanity – everyone knows that these “solutions” don’t work and they keep using them. 

It’s a simple case of cognitive dissonance when people believe two contradictory ideas. 

I guess we hope that one day in one special project it will magically workout. 

Let’s look at each project management fallacy in detail. Watch the video or keep reading…

Fallacy number 1: Add more developers to the project to increase the velocity 

Ok, your project is late. You only have 2 more months to the deadline. And the progress is clearly not as fast as you hoped it would be. 

Sounds familiar? 

So, let’s just hire more people to fix the problem! 

Say, we have 10 developers, and we were able to burn through 50% of our scope in 6 months…. 

So, if I divide the scope, by the number of months we spent…. 

50 by 6…. so 10 devs can complete about 8 points of work in a month. 

To complete the project on time we need to burn through 25 points of work per month… 

Ok, so if we triple the team, we can totally make it! 

I’ve seen people make this kind of calculation with precision to know exactly how many extra devs they need. 

Unfortunately, teams don’t work that way. 

If you’ve never heard of the 5 stages of group development, you can check out this video for more explanation. 

But briefly… 

Every team goes through several stages as teams get to know each other, learn the work they need to do, and build some basic effectiveness. 

And this can take months! 

Not to mention that when you recruit more people or even add new people to a new project, they will need time to go through the onboarding. 

If anything, bringing in more people to your project is going to slow it down in the short term as the existing people will need to help new people understand the project, the work, the processes, etc. 

As a Scrum Master who is managing a project you should add people when you plan for long-term productivity gains, not last minute because you are already late. 

There is a popular metaphor that some use here: “You can’t make a baby in 1 month with 9 women”. 

I don’t really like this metaphor as I think it’s too limited and doesn’t account for teamwork benefits, but it gets the point across. 

Anyway, if you find yourself in this situation, you have two options: either you move the date, or you cut the scope. 

The only other option is to squeeze people like lemons to the very last drop, and you might be able to get something out of the door before the deadline. 

I personally wouldn’t trust the quality of that something. 

In addition, the team members by that time will already have their resumes updated as they wouldn’t want to stay with you for another project. 

I talked about it in my scope creep video. 

In conclusion, adding more people to a project that is already late will only put more pressure on it making it even less likely to be on time. 

Fallacy number 2: Add a buffer to account for anything unpredictable 

That’s a popular one. If we add a buffer, a good buffer, we feel very certain that whatever is asked of us can be done. 

So certain that people give an absolute 100% guarantee. 

The problem with this is that even if we add a buffer, we don’t know if our initial estimation is even close to reality. 

So if you have estimated a project to take 6 months and 1 million dollars, but in reality, it is 18 months and 10 million dollars, even if you add a buffer, it’s going to be far off from reality. 

Now, I am talking about complex work here, not predictable and easy-to-estimate projects. 

An example that came to mind is running a marathon. 

If you’ve never even run before, can you promise me that you can finish a marathon in under 3 hours? 

What if I give you 5 years to prepare? What if you have an unlimited budget? 

I’m not a runner myself, but I know that each body has certain limits and certain capacities. 

In addition, there are other factors that may impact your success, like getting an injury, for example. 

When we look at a simple life example, it’s easy to see how ridiculous adding a buffer sounds. 

But when we are talking about multi-million dollar projects, somehow we forget about that. 

Taking a few quotes from my new favorite book “Essentialism” by Greg Mckeown: 

“Projects and commitments tend to expand to fill the amount of time (or money) allotted to them” 

Or as in this saying that was attributed to Abraham Lincoln: “Give me 6 hours to chop a tree, and I’ll spend the first 4 sharpening my axe”. 

So what can you do instead of adding a buffer? 

Well, treat forecasts as forecasts, not as guarantees. 

Consider any estimate as incorrect by default. 

Speaking more specifically: make forecasts for best-case and for worst-case scenarios to see how wide the uncertainty is. 

Remember a Scrum Master always plans for the worst case of the worst case. 

Fallacy number 3: Assign all work items in advance to specific people 

By this, I mean defining who will work on what in advance before the work starts, and locking everyone involved in it. 

These kinds of decisions are made without consulting the people involved…

…most of the time.

…ok, ok – often.

A product manager may define who on the team has which skills and what they will work on. 

What’s the problem, you ask? 

Here are some essentials factors that are not taken into account when making that decision: 

• Knowledge and skills of team members that we may not be aware of. 
• The personal interest of the team members in working on certain projects or products. 
• Professional development and knowledge transfer. 
• And, interpersonal relationships between people involved in the project. 

These are the biggest ones I think. 

So what often happens is that the work is started, and then we learn things we didn’t know about (because we never asked) and that drastically impacts the project’s success, like: 

• One person assigned to the project has been working on transferring to another department because they no longer want to work on the projects that are being assigned to them. 
• The person who is asked to work on a certain task has the knowledge and skills needed, but there is someone else who would be a much better fit for it. 
• Two people added to the team can’t stand each other and end up working in silos. 
• Because the same person is always assigned to the same types of task, no one else in the company knows how this part of the product works and that slows down everything else dependent on it.

These are just a few examples of what may happen. 

And most of these could be avoided if only you let people to self-organize.

To do that you need to set very clear goals and milestones, and then give it to the people who will be doing the work. 

Their job is to identify what skills and knowledge they will need to succeed, and who can be a potential candidate to fulfill those needs. 

Not only this can help you avoid some of the problems as you start working, but you will also save lots of time for people who have some high-level decisions to take care of, instead of assigning work to people.

Fallacy number 4: Splitting people’s time between multiple projects 

Ugh….

I have so much to say about this one…

You know when one person is assigned to 3 projects just because they are the only expert on a particular area of work?

This leads to basically everyone in all three projects being dependent on that one person.

This in turn leads to a lot of stress put on an individual who may start working at an unsustainable pace and eventually end up burned out.

A lot of time is lost due to context switching and simply attending all of the meetings for all of the projects.

And in addition, it is a planning nightmare!

How are you supposed to define whether you worked 30% of your week on a particular project? 

And when someone is waiting on this one person to complete a task, and they just physically can’t do it within the expectations set, then we start asking – how many hours did they spend on this? can the other projects wait? which task is more important?

…

As I said in the beginning: “Ugh… I have a headache” 

I once used this graph to explain to one of the managers the effects of assigning the same person to multiple projects.

The graph shows how much time is being lost to context switching and how much time in reality people can spend on the projects versus what’s expected of them.

He looked at it for a few seconds, and then said: “So what?”

If you are watching right now, though I doubt you are, do you remember that? Yeah…

But let’s take this question seriously. 

So what do we do if we can’t have every person working on a single project?

I have an easy answer: plan for the time lost to context switching. 

Assess how much time realistically one person can dedicate to multiple projects. 

If they are split 50/50 between two projects, then count their capacity at 80% only.

Are they split between three projects at 30/30/40? Then count their overall capacity to be at 60% of their usual.

What? You don’t like my maths here? 

Then plan for knowledge transfer or hiring more people. 

Fallacy number 5: Reporting the“watermelon status” for as long as possible

This is the number one mistake for a project manager.

Here I’m talking about keeping the challenges the project faces hidden in order to not upset the stakeholders without reason.

Green on the outside, red on the inside.

For example, the project is not going as fast as everyone hoped.

But instead of raising this as an issue immediately, people kind of think that they will pick up the pace in the upcoming months.

“We still have plenty of time, right?”

And then if the project is really not going well, then the team is just fearful of admitting it as they know it won’t be taken well.

So they postpone delivering the news for as long as possible.

This of course is not going to play well.

What’s even worse is that if the information is reported earlier, maybe there is a way to improve the situation.

But we usually learn that way too late when nothing can be done. 

So while it seems that we just don’t want to attract unnecessary attention to the problems the project is facing, if we wait too long… 

Well, we will break the last drops of trust that may exist and we will rob ourselves of an opportunity to succeed.

A Scrum Master knows to be able, to be honest about the project status, there needs to be trust. 

Building trust requires courage. 

And that means that someone has to take the first step.

Summary

What did we learn? Let’s summarize:

• Adding more developers to the project to get it done fast will only slow it down in the first months due to the learning curve and team formation. 
• Adding a buffer to the estimated timelines is almost always off anyway, so it’s best to just share progress along the way to set expectations.
• Assigning all work items in advance to specific people may lock you into unexpected situations and will not allow you to distribute work in the most optimal way.
• Splitting people’s time between multiple projects will make them lose a lot of time to context switching and should be planned for in advance to keep a sustainable working pace.
• Reporting the watermelon status for as long as possible will only break trust and will not allow the team to make improvements when they may still be valuable.

I hope you learned something new, and if you did – share what it was in the comments down below. Do you agree with my evaluations? 👇