Project Management for Remote Teams

I’ve been working completely remotely for around 2 years now. In that time, I’ve experimented with different workflows and combinations of tools to try and achieve the highest level of productivity while minimising unnecessary busy-work.

Although working remotely does present us with some unique problems, most are just reformulations of problems we usually face when running any kind of project.

Making sure progress is consistent, sharing information amongst team-members and maintaining healthy relationships are not new project management problems – they just need to be handled differently when team members are not working together in the same room. Or city. Or country.


 What challenges do we face managing remote teams?

Remote work has some unique characteristics. Firstly, the fact that your team is not in the same physical location immediately rules out all forms of physical communication. As well as this, team members are likely to be working different hours, and may even be located in different time zones. Finally, remote contracts are by their very nature more volatile – employees can leave (and join) your team more easily than traditional working arrangements.

These characteristics present us with some unique challenges.

Establishing effective communication channels

Making sure people know what they need to know when they need to know it is one of the biggest concerns of a remote team. It’s also worth mentioning that too much communication is almost as bad as not enough.

The priorities when managing communication amongst remote team members is to minimise information overload and keep the team focused on the important objectives. We also want a single source of truth – one place where everyone can get stuff out of their heads and into a place and format that everyone on the team can see and use.

Tracking and ensuring consistent progress

Another important concern is accurately measuring progress, and then making sure progress is consistent. We need to ensure work is getting done and the wheels are always turning. Without an effective way of tracking progress it’s far too easy to let a slow week of progress slip under the radar. And then two weeks. And then a month.

Maintaining an accurate view of what has and hasn’t been done provides us with two benefits: it keeps the project progressing and provides a constant sense of momentum, which is useful as a motivational tool not only for the team but for the project manager and/or business owner.

Creating and curating company culture

This is one of the most overlooked concerns when building a remote team, but it’s incredibly important. Creating a positive company culture is a key factor in making sure your contractors give you their best and most creative work and stick around longer than a few weeks.

One of the most important ways you should be doing this is by getting your employees emotionally engaged in your projects. To do this, you need to communicate two things: 1) that the project is something worth being a part of (serves a higher purpose and is here to stay: think long-term, not short-term), and 2) they can be a part of that bigger picture.

When a contractor stops working on your project(s) for a couple of weeks, they become emotionally disengaged from your company. It’s when that disengagement happens that it becomes psychologically acceptable to stop responding to your emails, to stop hitting deadlines and to let the quality of work slip.

Remote work presents us with some unique challenges

Remote work presents us with some unique challenges

 


Slashnode Project Management System

In my consulting business, we use a five part project management system. Each part of the system contains a set of tools and workflows that function together to deal with the previously mentioned challenges.

  • Project requirements. A set of documents detailing the high-level requirements of the work that needs to be done in order to successfully execute the project.
  • Product backlog. A complete record of all the individual low-level tasks that are involved in finishing the project, as well as the current state of each task (not yet started, currently in progress, finished) and any information required to complete the tasks.
  • High-level communications. A medium for high-level, strategic and scheduled communication.
  • Low-level communications. A medium for low-level, tactical and “always-on” communication.
  • Project delivery. The “production line” where project deliverables are shared between team members, clients, customers, etc.

Note: this post is specifically tailored for software businesses, but the ideas and approach can be adapted for other remote digital companies.

 

1) Project Requirements

The starting point is to define the work for the team. The project requirements usually involve technical documents, reference materials, architecture diagrams and wireframes.

I find the easiest way to do this is to create wireframes and diagrams using Balsamiq and Sketch, and then share them with the relevant team members using Google Drive.

Balsamiq is useful for low-fidelity mockups, which I’m a big fan of, especially during the early stages of projects. Low-fidelty mockups / wireframes enable you to communicate the important high level details of your requirements without forcing you to make decisions that can be pinned down later. Sketch is perfect for more complicated or high-fidelity mockups.

Google Drive is useful for sharing because it enables you to control on a granular level who can and cannot view / edit different files. It also has a bunch of useful features like version-controlling files, and integrates nicely with Google Apps for Work (which is what we use for email, calendars, etc.)

Google Drive for Requirements

Requirements documents, saved and shared using Google Drive

 

2) Product Backlog

The project requirements define the work in a strategic, high-level and abstract way, but that isn’t particularly useful for day-to-day operations. We also need a way of keeping track of the detailed, low-level requirements of the project. This enables us to break up the larger body of work into individual tasks which can assigned to members of the team.

We also need one true source of truth – a place where all the work to be done and all the work in progress is kept track of. This means we don’t need to piece together information from different sources to know exactly what’s involved in completing a specific task or how much work has been completed. As a result, we can easily reassign tasks to different team members without redundant communication.

I recommend using Trello. It’s free, easy to use and perfect for small teams and/or small projects.

I set up the following lanes:

  • Backlog: all the work that needs to be done, but hasn’t yet been completed. Cards usually include references to the requirements in Google Docs, as well as diagrams and/or wireframes of the desired outcome for each card.
  • Blocked: tasks that were started by someone, but cannot be completed because more information is required or another task needs to be completed first. A major priority for the project manager is to make sure “blocked” items are unblocked and moved to “In progress” as quickly as possible.
  • In Progress: tasks that a team member is currently working on. An important rule: each team member should have one and only one item in this lane at any time.
  • QA: when a team member has finished a task, they move it to “quality assurance.” The project manager will then test the functionality to make sure it’s working and then move the task into:…
  • Done: completed tasks. Cards in this lane get archived on a weekly basis.

A graphical depiction of this workflow is provided below.

A graphical depiction of the Trello workflow for team members.

3) High-level Communications

We need a way to communicate at a high-level about the project requirements, company vision and overall progress of the undertaking. In a typical office environment, we would use meetings for these discussions.

It may sound counter-intuitive to imply that remote teams should have scheduled meetings. Isn’t avoiding time-wasting meetings one of the most attractive arguments for turning your team remote?… but hear me out for a moment.

No – we shouldn’t have meetings as prescribed by the standard office protocol. That is: vaguely scheduled for at least 30-60 minutes, occurring in a physical meeting room with no agenda and no strict end time.

However, quickly speaking with your team a couple of times a week about prescribed, outcome-driven topics is a beneficial thing. It enables you to keep your team on-track and aligned with your vision, and provides an important relationship building opportunity.

We achieve high-level communication via two mechanisms:

The Weekly “Stand-up”

This occurs at the start of the week on Skype. Developers will be familiar with the concept of a “stand-up,” which comes from Agile development methodologies. It involves meeting first-thing in the morning before starting real work, standing around the product backlog and discussing three things:

  1. What did I accomplish last week?
  2. What will I focus on this week?
  3. What obstacles are impeding my progress?

Make it short. 15 minutes on Monday or Tuesday morning is good. Have a simple agenda and make sure everyone sticks to it. Take notes of any action items and make sure they’re recorded somewhere everyone can see them (In Trello, or in an email sent after the call).

End of the week progress email.

All team members send a quick (approx. 3 sentences) email to their project manager at the end of the week. The email contains answers to the following three questions (similar to the “stand-up” questions):

  1. What did you achieve this week?
  2. What problems or potential roadblocks did you encounter?
  3. Can you provide potential solutions to those problems or roadblocks (if any provided)?

You can see an example of a weekly update email here (specifics removed):

Date: Fri, x Jan 20xx

Subject: Weekly Update

From: User One (userone@domain.org)
To: Corey McMahon (corey@domain.org)


This week I worked on A and B. I did some thinking about C and how it should work - but it looks like you spec'ed it out.

The only question I have is D?

I think it might be E, but I'm not sure.

4) Low-level Communications

While the weekly Skype and email system is used for high-level, strategic purposes, we still need a way of managing the day-to-day operations and communication between team members.

While email could be used for this, I much prefer an “always-on” chat solution such as Slack. It archives all chat sessions, so team members can refer to it later if they can’t remember what the answer to a particular question was. It also enables you to create multiple “channels” for different discussion topics. A decent general channel set-up (and what we use) is:

  • One channel per project for general project discussion.
  • One channel per project for automated alerts. We integrate with Trello and GitHub, so any activity for the project on these channels is also reported in Slack.
  • A company-wide “banter” channel for non-work related discussion.
  • Individual “private message” sessions with team members for one-on-one chat. Any decisions that affect the project or team on a broader level are manually copied or communicated from the PM session into the general project channel.
Low-level communication using Slack

Low-level communication using Slack

5) Project Delivery

The final part of the system is actually enabling the team to deliver the project in a collaborative fashion. How you achieve this will depend on the type of project. We build software, so we use GitHub private repositories to host our deliverables.

Warning: software jargon below. Not necessary reading if you aren’t in the software business.

We use git-flow.

Team members open pull requests against the development branch (appropriately called develop) of the repository they’re working on. Pull requests always need to reference a Trello card number. This prevents team members doing work that hasn’t been defined by a project manager (if there isn’t a card for it, they can’t work on it).

Project managers then test the feature branches by checking them out locally and running through the use-cases / user stories. If there are any bugs or changes required, the project manager adds comments to the PR in GitHub, and then updates Trello as described above. If the project manager is happy with the changes, the branch is merged into develop.

When we’re ready to release features, we merge develop into master and add a version tag. For our Laravel projects, we use DigitalOcean and Forge for hosting and continuous integration.

Using GitHub for Project Delivery

Using GitHub for Project Delivery

 


And that’s it.

These are the processes I’m using at the moment to run our projects. So far everything is working well, but I’m always looking for new ways to improve them.

I’d love to hear how other project managers, developers and entrepreneurs are getting the most out of their remote teams.

 

So… what about you? How do you work with your remote team?

Tell me in the comments below.

  • http://speakmy.name morhekil

    Interesting read. How do you prioritise tasks for the team? Is it just an order of cards in Trello (top to bottom), or something more fine-grained? Or is there just not that many tasks in the backlog, and everyone picks what he wants?

    I use a somewhat similar workflow when working with my teams, but I always preferred to add a solid bugtracking system to my stack – be it just Bitbucket’s issues for a really lightweight projects, or Redmine/Jira/Unfuddle for a medium-sized ones. I found that when there’s a page for a task (a ticket), it helps to collect all related documents, conversations and other info in one place, and makes it much easier to come back to it later to remember what/why has been done.

    Do you find Trello working fully as that kind of tool for you?

    • http://www.coreymcmahon.com/ Corey McMahon

      In terms of prioritising, it’s as you mention: top to bottom. For most projects this is straight-forward because I work with full-stack developers, so it usually doesn’t matter who works on what. If you want a specific team member to work on a task you can assign them as a member and leave it in the backlog.

      I’ve used a pretty decent number of different project management tools (JIRA, Asana, BaseCamp, BugHerd, Sprint.ly…) and find that while added complexity is useful for bigger teams, for smaller teams and projects Trello forces you to keep it simple. As a team grows I’m more inclined to scale “horizontally,” that is: to break the team into smaller groups that replicate this method internally with their own backlog / Trello board. Also note that you can actually upload attachments, link to other resources (e.g.: Google Drive) and conduct conversations on Trello cards… although I have to admit it does get hard to navigate pretty quickly.

      More complicated tools like JIRA do have a place when you need to coordinate work and manage the flow of information between different teams (product design, development, QA / testing), but for most projects I think they introduce too much busy-work and cognitive overload.

      • https://unfuddle.com/ Danny Han

        Hi Corey, thanks for this blog post. Found it while curating for content. I wanted to invite you to check out Unfuddle ONE at https://unfuddle.com/one/. It’s our one page project management tool that uses a very simple approach (much to your point above). I hope you’re able to give it a try. I’d love to hear your thoughts, even! -Danny @Unfuddle

  • http://davidhehenberger.com/ davidhme

    Great post. My workflow looks similar, but there’s a couple takeaways in here that I’ll apply to my business.

    I’m currently having my developers send “End of Day” instead of “End of the week” progress emails, but usually not that much happens in a single day. I might move to weekly too.

    Also, I haven’t been doing the ‘standup’ skype calls. In my case of multiple team members in multiple time zones working on different projects, it probably makes sense to set up individual calls instead of group calls?

    • http://speakmy.name morhekil

      David, do your developers work as a team, or are you just managing them individually? I found team stand-ups important to bring the team together, as they have much more communication bandwidth compared to chats/emails. Everyone gets a sense of what is happening across the team, and might throw in an interesting idea, raise a hand to join on task he’s interested in, etc. If nothing else – just people chatting to each other informally helps the keep the feeling of a team, instead of just individuals working off the same backlog.

      Individual calls, in my experience, slide more towards one-on-one format. They are also very valuable, but serve a different purpose in my book – one-on-one gives a direct feedback from an individual, and helps to keep him happy and engaged, instead of getting team-level feedback and interaction at standups.

      PS: I hope Corey doesn’t mind me jumping in with feedback here! Please take it with a grain of salt, as just my personal experience/opinion, of course.

      • http://davidhehenberger.com/ davidhme

        Right now I have 2 devs, both of which mostly on different project. However, sometimes they’re collaborating.
        I think it would be good for both of them to be on the same page in terms of where the business is going, so I’ll try to set up group calls.
        Thanks =)

  • Meanu Normia

    Thats a depth insight, Working with remote teams is a tough task itself, We here use proofhub for managing everything from tasks to projects. Its easy to track and plan with these kind of tools.