How to Avoid Overwhelming Your Team When Implementing a Work Management System


Are you trying to implement a work management system like Asana, ClickUp, or Monday, and hearing your team say things like “I’m overwhelmed!” or “it was easier before we had this system!”? 

If so, you’re definitely not alone.

We help so many companies who are trying to get work management systems implemented, and for most companies, this is no easy feat to do on their own.  These systems have a ton of features and unless you’ve implemented them many times before, you have no idea what the “best practices” are that will help you avoid scaling issues in the future.

Fortunately, it’s easy to tell when teams are about to hit an impasse because you’ll start hearing at least one of the following:

  • “This is overwhelming (so I ignore it)!”
  • “This is more work than before we implemented this system!”
  • “I didn’t know the best way to do it, so I did _____________!”

These are all indicators that something has gone awry during your work management system roll-out.

But, not all is lost!  If you’re hearing these things, it means you’ve already knocked out some initial steps and you’re ready to start optimizing. Don’t scrap it all and start over, it can be salvaged. 

And more good news… after hundreds of engagements, we’ve identified a single factor that helps shift a team from being “very overwhelmed” to being streamlined and efficient in any work management tool.  

The key factor is Project Granularity.

I know that sounds like a code name for some underground government project, but fortunately, it’s a lot less scary than that.  Project granularity refers to the overall complexity of a project’s design.  

Uber-granular Projects

On one side you have uber-granularity.  With this type of project, every single step is mapped out no matter how big or small.  All dependencies are mapped.  All assignees are defined. All dates are plugged in.  Tasks contain subtasks and subtasks may even contain specific steps. The goal is usually to make sure that nothing is missed. Ever.

While there are instances where it makes sense to have uber-granular projects, a majority of the time that is overkill.  Here’s what we see typically happen:


A lot of time is spent creating the “perfect” project that includes every step

A lot of tasks are added to this project

These tasks are spread across one or more people

This project is converted into a template

This template is immediately used multiple times

In this scenario, what happens to the members of the project team? They get spammed with a huge amount of tasks, all at once.  Most of the time this happens before the project is even tested.  Things like priority are often missed.  And each team member is left with X tasks multiplied by Y times the template used.  Were they even trained on task management before this happened?  Probably not.  How do they react?  They say things like “OMG, I’m overwhelmed af, right now!”

Uber-granular projects have their place, but they are not only hard to design, they require an extremely well-tested and effective process to implement and need a team that is well-trained in handling hundreds of tasks being thrown their way.  

And, even worse… what happens when the process needs to change?  You’ve baked every step of your process into the template and used it multiple times. Do you delete all the active projects and start over with an updated design?  Do you edit all the active projects?  Do you keep old projects with the old process and new projects using the updated process?  None of these are great options and leave you in between a rock and a hard place.

But, it’s not all peaches and cream on the other side either.  Let’s stroll down that path and see what it looks like… 

High-level Projects

On the other side, you have very little to no granularity.  A project of this type is going to live in the ‘high-level’ perspective.  It may still have some assignments, dependencies, and milestones, but they are going to only represent the high-level phases of the project itself.  The actions taken to achieve these milestones will be up to the team and/or assignee responsible for them.

When you have a high-level project, you’re going to avoid the task overload, but unless your team has memorized the process, they will have no idea how to achieve any of the milestones.  And, even if they have memorized the process, you’re still opening your team up to human error, reinventing the wheel, and miscommunication and/or misunderstanding.

So, how do you solve the problem?  How do you design projects that don’t overwhelm your team and yet provide enough detail so that people can achieve milestones without human error or miscommunication?  You need to introduce the missing piece:  Clear documentation.  

Goal: Simple Projects with Clear Documentation

By combining clear documentation with high-level project design, you have a defined project plan with milestones and a playbook that shows exactly how to achieve those milestones.  The number of tasks that end up in the project team’s inbox is dramatically reduced.  Human error is solved because any questions can be answered by watching a video, following step-by-step instructions, or reviewing a diagram all contained within a playbook that’s linked or embedded directly into the milestone task itself.  And, as a bonus, when you need to update the process, you can simply make a change to a single playbook and that change will be automatically reflected in any project past, present, or future, that links or embeds that playbook.

If you’ve experienced something similar and are looking for some help. Reach out!  Our team can help create a powerful foundation that allows you to scale quickly.