Did you know you’re wasting hours of time as a project manager? Not in the way you would expect—meetings, emails, and chats are all a part of our daily lives and job descriptions. Instead, I’m talking about things that can help save you time and stress in your day-to-day project planning: task automation, communication habits, and project planning hacks that can make all of our lives a little easier.
Over the years I’ve learned there are so many little tips and tricks I’ve learned myself and from my peers to be more efficient and shave tons of time off of my daily workflow.
10 Project Management Hacks To Boost Your Productivity
Read on for 10 project management hacks that have helped me become an even better DPM and be sure to check out the podcast for a deeper discussion on these hacks.
#1. Automate your project management tools as much as possible
Slack, Google Calendar, email, whatever: become an expert in the tools you use and the automation opportunities they offer so that you can help yourself and your team painlessly sync information across platforms. Making the most of the tools I use saves me buckets of time in the long run—instead of repetitively checking in and out of the same tools and notifications, I use integrations and fine-tuned settings to help me use tools in exactly the ways I need.
Here’s how to do it:
First, set up integrations between all of your tools where you can. I use Slack, Trello, Dropbox and Google Hangouts frequently on my projects. Slack is the main app I use all day, and the other tools I use all have Slack Apps that will hook right into my accounts for easy and quick access:
The Google Hangout integration allows me to start a hangout in Slack with a short slash command, and the Dropbox integration means that I can share and upload files quickly and easily from my Dropbox account right to Slack. The Paperbot App (thanks to The Digital Project Manager Community for introducing that bot to me!) sends me a daily or weekly digest of links shared within team channels, which is so helpful when I know I’ll be too busy to comb through channels for updated files and project links to review, or if I go on vacation and don’t want to be too connected to Slack, but want to stay up to date.

Slack commands are amazing: with the Google Hangout integration, creating a hangout is as simple as typing in “/h” and pressing enter.

Slack automatically pulls in images shared via Dropbox link when an image file is shared, saving me from having to upload a file and saving my team a click to load the link.
There are plenty of automations you can look at outside of Slack too: I’ve configured Dropbox to be the default screenshot preference on my computer, which automatically syncs the image to my account and copies the shareable link to my clipboard—which makes giving feedback or bug reports take mere seconds if I’m in a rush. Google Calendar has fairly robust notification preferences, which means if I schedule a big meeting a month in advance I can have it email my team 3 days before to remind them to prep, without me having to worry about remembering.
#2. Use a RACI matrix on every project you manage
A RACI matrix is a tool that outlines responsibilities, roles, and ownership on a project to avoid confusion over tasks on projects and sets expectations from the start. Creating a RACI matrix at project kickoff saves time on a project from the start: it sets expectations and communicates to everyone what their roles are. These charts can be used at almost any point in a project for easy reference and clarity without extra work.
Here’s how to do it:
A RACI matrix can be as detailed or simple as you want it to be, but the key is to make it work for you and your project. Create a quick spreadsheet template to re-use in the future, or even go the paper route to map out these needs quickly. I’m a fan of using RACI charts for all sorts of project needs: from project responsibilities overall, to mapping out the content management workflow (which I’ve described and demoed in the past), to launch needs and responsibilities. Depending on the complexity of the project, it can help to break down RACI decisions into multiple charts.
Here’s an example of a simple, high-level RACI matrix:

I use this level of detail mostly for myself and to go over with a project client at the beginning of a project. It’s enough to set expectations about responsibilities and make sure everyone is on the same page, and consumes little time to update and share—it’s almost always the same on each project. On complex projects, I create more workflow-driven RACI charts if needed. For example, it might include detailed steps for a particular stage, all of the team and stakeholders involved (rather than just leads), and contingencies for how each type of responsibility will be communicated or acted upon.
If you want to dive deeper into RACI charts, I totally recommend you reading this amazing article by Suze Haworth.
#3. Say hi to your team and coworkers daily
Ok, maybe this one seems obvious—but hear me out. Greeting someone or having a casual conversation with that individual helps you get to know them a little better. By contributing to a positive environment and creating an opening for casual conversation, you build trust and naturally create a channel to chat with teammates about trivial or non-trivial things going on in their lives. That means that they will feel more comfortable opening up to you on minor issues before things turn into large roadblocks down the line. It also helps your team ask for help or speak up about better solutions on projects more frequently and informally.
Here’s how to do it:
Check in casually with the full team regularly. I default to striking up conversations at the end of most weeks in my team Slack channels—asking about upcoming weekend plans is an easy conversation started. On a personal level, I try to chat with individual team members once a week or so when I’m working on a project with them. I make an effort to say good morning and ask how they are doing, making sure not to follow up with some work-related need or question during that conversation. This creates a friendly and motive-free chance for us to get to know each other a bit better. Ultimately, my goal is to build a sincere habit of communication so that either one of us can reach out to the other more easily if it’s needed.
#4. Learn to say “no” on a project gracefully, but firmly
Saying no is one of the most difficult and empowering things we can do as project managers. Whether it’s rerouting a poorly-timed scope change, protecting our teams from unnecessary stress, or making sure we’re not overloaded ourselves, we need to be able to say no (when appropriate) professionally and confidently.
Here’s how to do it:
The hardest part for me is knowing when I should say no to something. I’ve gotten better at it over time by understanding my project boundaries but it’s helpful to keep a mental list too. Here’s my shortlist of requests I’ve realized I should say no to:
- When what I’m being asked to do is only possible by breaking a non-negotiable promise, a major priority, or will impact non-flexible priorities of others.
- When what I’m being asked will put the project health in jeopardy.
- When what I’m being asked will force my team to work in a way that is not productive or ideal for their work.
In each of these situations I make sure to explain my reasons for saying no, rather than giving a harsh answer. For example, when a client asked my team to add an Events function to their site two weeks before launch, I said no, and explained that there were a lot more implications to consider than just adding an Events page (ticket sales, user tracking, checkout, etc). They quickly understood this wouldn’t be an ideal use of our time so close to launch, and together we moved forward with linking to a third-party event page for the time being instead.
Tip: Setting project and team goals helps make it even more clear when to say no during a project.
#5. Treat your projects as learning opportunities
While each of your projects might fulfill patterns you’ve seen on past projects, treat each new project as a unique learning opportunity for yourself and your team. Take opportunities with new projects to learn a new skill, further your understanding on a particular topic, take on a difficult challenge, or use it as an opportunity to vary your communication style or how you use and pull data on a project. It can mean the difference between a project that just meets its goals—or exceeds them.
Here’s how to do it:
I’ve gained tons of knowledge from successful projects and have learned from past mistakes too. The easiest way to set yourself up to learn on new projects is to conduct a project retrospective after the last project finishes. Retrospectives have helped me understand what I need to do better as a PM, what my team struggles (and succeeds!) with, what processes do or don’t work for us as a team, and gives me insight into many things that I might not otherwise realize.
Ask the following project retrospective questions of everyone on the project team:
- What did we set out to accomplish?
- What actually happened on this project?
- Why did it happen?
- What are we going to do next time?
Take the answers your team comes up with and apply them to your next project—you can even create process change from retrospectives if it’s needed.
#6. Take control of your notifications
I tend to be a reactive DPM—I hate seeing notification badges or unread messages anywhere, and I use this knowledge to my advantage when I’m setting up new accounts or preferences on my tools. I utilize every notification setting available to me and am ruthless about muting or hiding unnecessary notifications. I know those will just draw me in and I won’t be able to wait long enough to batch my message checking—so instead, I am rigorous in setting notifications to work for me instead.
Here’s how to do it:
I use Slack for most work chats and luckily, Slack has a lot of customization available for notifications: I don’t use dock notifications for anything social, I mute channels that I monitor but don’t actively PM, and set keywords for project-related accounts so I don’t need to catch up on chats if I don’t have time.

I removed almost all notifications from Slack accounts so that I only get pinged about super-relevant, project-related needs.
Most project management tools aren’t quite as granular as Slack, but many have email digests and project reports that you can configure on a per-project basis to bring more sanity to your notifications. I also review and update my notification preferences every few months if I notice I need something different or am still sorting through more information than I need.
#7. Educate as much as possible
Provide context for your communication and project decisions to your team and your clients whenever you can. Explain why things are moving in a certain direction, why you need to know the things you’re asking of your team, and explain any deep-rooted technical information to your clients in a way that they can understand without feeling overwhelmed. Similarly, use any question as a learning opportunity for yourself—ask for context from your clients and team, ask for more clarity if you don’t understand a concept, and learn more whenever you can.
Here’s how to do it:
Every few months I ask the technical lead on my projects if I can schedule an hour or two to chat more about a concept I don’t understand, especially if it’s being heavily referenced or utilized on my project. I’ve done this for all sorts of things: DNS issues, server configurations, and complex integrations that were featured heavily on my projects. This has worked to my advantage and helps me better plan what information I need to gather from my clients during a project, gives me a more accurate sense of when an expert is needed, and I can spot technical red flags on a project more quickly now.
I’ve brought in design leads to regular weekly client calls to better explain vision or decisions on a project too, to give some contextual knowledge to a project stage that might be especially opaque. There is definitely a point where someone might not want or benefit from being overloaded with information, but practical education can make for more transparency and context around decisions at the end of the day if it’s presented thoughtfully.
#8. Say “i don’t know” more often
Being able to say “I don’t know” to a client or team member is a powerful thing. It gives you the chance to pause and collect more data as needed, and get input or context where you’re missing that piece of information. The most difficult thing I’ve learned over the years has been to say “I don’t know” more willingly and freely—it can be easy to feel like we need to have the answers as project managers, but that’s why we work with our team (the experts) to do what they do.
Here’s how to do it:
I definitely don’t want to sound like I don’t know what I’m doing by saying “I don’t know” at the wrong moment, but it’s easy to make this phrase work in the context of a meeting or call. Especially during a tough project call, I’ve found it helpful to qualify my “I don’t know” statement with a few helpful phrases. Some examples: “The development lead would have a much more accurate answer than I can provide—let me have them follow up.” Or, “I’m not the best person to answer that, but I’ll reach out to the design manager and have them explain.” In the event that you don’t necessarily want to admit that you don’t know, you can always frame this more simply: “The tech lead can answer that. I’ll loop them in.”
#9. Use email filters/automations to your advantage
I love using automatic filters and saved responses in email. Having emails automatically labeled or sent to a folder saves me lots of time just sorting and processing emails when I’m extra busy or out of the office. It allows me to get right to the important things when I go back to read and respond to emails once I have time. Templated, saved or “canned” email responses are great to give you a starting point for certain types of emails you might send regularly.
Here’s how to do it:
I write several similar emails over the course of every project, so I keep a set of templated emails through the Gmail “Canned Responses” feature so I don’t have to rewrite the same thing each time. If your email client doesn’t offer a similar feature, a text document or notepad file works just as easily.

I’ve saved a standard kickoff meeting, status report, post-meeting follow-up, launch, development details needed, and design brief email for myself.
I also use email filters to the most detailed extent possible. Outlook and Gmail both have powerful filtering options, which allow you to pre-define rules for incoming messages. I use these to automatically mark several types of emails so that I can easily read/find them later: client emails get automatically labelled by project name and moved to my Priority inbox in Gmail, project tool notifications get marked as read automatically and moved to a non-priority inbox (where I review them at the end of the day on my phone), and internal emails get labelled as internal and marked as read (for later review) if I’m listed as a CC and not the primary recipient of the thread.
#10. Always know the numbers
Pulling data on a project can give you a strong idea of where a project stands and what issues might appear in the near future. I’m a huge proponent for pulling data early and often—not just to educate yourself and stay in the know, but to be able to understand the ramifications of account or project-level decisions. Understanding the project numbers as the project is happening gives you better context for the overall project, and allows you real-time opportunity to bring the numbers to your client or account team if something needs to be adjusted or reconsidered—instead of waiting until the end or critical point of a project.
Here’s how to do it:
I work on a variety of projects: time and materials based, one-off projects, and retainer-based projects. The type of project usually dictates what reports I want to regularly pull, but the idea is similar through each project. This is usually what I keep an eye on:
- Time reports
- Team velocity
- Number of tasks done/in progress/left
- Vacations and resourcing until launch date
- Budget utilized or left so far
Keeping an eye on these items on a weekly (or even several times a week) basis helps me immediately see trends that seem outside of the norm of the project so far—which usually indicates some sort of issue. It also helps me see if there is any information that might be missing or incorrect early on, avoiding big surprises that might be found out if I’m only checking every few weeks. Pulling time and budget reports is the biggest indicator of project planning issues that I want to understand and communicate to the client along the way. But looking at task completion rate and team velocity also helps me see if there are internal process hurdles to work through—like a feature being more complex than anticipated or not having enough resourcing available for a project.
Pulling this data and understanding what the project looks like from the reports I pull helps me get a sense of the overall health of a project and review areas that seem problematic before they get to a point of no return.
What Do You Think?
You don’t have to employ every single one of this tips verbatim to start saving time and stress on your projects—even one or two will make a difference.
If you’ve been project managing for a few years, you’ve probably even created many of your own project management hacks to get by more efficiently. Let us know what you like to do in the comments so we can all try it out!
Related read: The Rise Of Productivity Paranoia In The US And How To Navigate It
3 Comments