Some Suggestions on How to Improve Project Management on a Fully Remote or Any Team.

Doist, a fully remote asynchronous company, has been experimenting with what project management should look like for them. I applaud much of what they are doing but at the same time I shudder a bit. What causes me concern is some aspects of reinventing the wheel.

Now we need to start with a little background on me. I'm not a certified project manager and I don't want to be. I am a pragmatic and experienced leader from the trenches. I've put in my time in development organizations for the last 21+ years. I've seen what works. I've made mistakes and I've made corrections. I despise waste including unnecessary bureaucracy. I can find my way around Microsoft Project but that doesn't mean I like the tool or how overblown it is. I'm also the first to admit that you don't need a heavy Gantt chart to manage a project well.

I'm not a fan of formal project management pedagogy for pedagogy's sake, but there are some gems even in the midst of all the posturing of certified project management. There are also gems in the midst of all the Agile purity as well. The trick is finding those practical gems and applying them across every project not in a prescriptive way but in a adaptable one.

So Doist works in a work breakdown they call Doist Objectives (DOs) centered on project-based squads. Each squad is temporary and cross functional working on a specific goal for one 6-week cycle. My first suggestion is to take the concept of cycle and keep it but figure out what works for Doist and even for a given team. One-week cycles are painful, but damn if they don't teach you quickly what you suck at and what needs improvement. You don't have to stay with these forever but you may find they are the best for or a team or something in between. I'd urge going radically short and then increment up versus starting with 6 and slowly decreasing down.

Doist’s post asks several questions:

“Is it possible to effectively manage a project in a lightweight way without getting bogged down with complicated methodologies and GANTT charts?”

Yes use visual planning. Use a virtual whiteboard  (e.g. Real Time Board)with Post-Its so that there is a single source or truth that the team can get to. Add connecting lines like the string boards you see on crime dramas to connect dependent tasks. Gives you a quick and easy way to see when you are in trouble with dependent work happening too late.  Plus no need for synchronous communication using this method.

“How can project management be adapted to a remote team setting where the majority of communication happens asynchronously?”

You use the four-letter word process.  You put in place a lightweight process that provides consistency and checks all the essential boxes with no wasted effort or unnecessary meetings. That light weight process should tick the following boxes:

1. Well worded specifications that feed into clear requirements. Yes there is a difference. Specs tell you what you are trying to do and requirements put some guide rails on how you are going to do it. They need to be carefully aligned with companies priorities and that needs to be clear and compelling to everyone on the team. They need to be testable and talk as much about what you are going to build as what you are not.

Doist’s example of a specification/goal is not good:

“Problem: Not many people reach Todoist Zeron on a consistent basis.

Solution: Make the experience of reaching Todoist Zero more delightful.”

First is this goal driven by user need? Has marketing validated with the end user that this is high priority must feature?

Next as written today the solution to this problem could be an infinite number of solutions. More specifics on the limitations of how to implement this feature either due to technical, time, or money limitations is going to help focus the development work. Take it a step further and do even a brief high level end user test with less than 5 users as early on in the project as possible. Even one is better than none and incorporate their feedback.  If you can check again at the end excellent if not that’s OK. Do user testing early when you can act on their input at the least cost to the project.

1. Take the project to the team and let them help you identify the correct team members. You don’t need to know it all you just need to know who does.
2. Take the project again to the team and get their estimate of the work as a group. You can break this into smaller chunks of work or “stories” but use the group to size the effort of each. It will remove any individual bias.  (Pro tip track how the team does against these estimates for the future when you might tackle a similar project or to see how your process is getting better or could be tweaked to improve.)
3. Create some simple prototypes of the UI/UX, drawings, presentation, flow chart. Couple those with the time and effort estimate you’ve got and the project goal. Check again with your stakeholders that the project is still a go. You’ve spent relatively little at this point. It isn’t a bad idea to even keep doing this as the project progresses. Better to kill something early than get to the end having expended lots of time and effort and decide the need for the project isn’t still compelling.
4. Start your project, control your versioning, track your defects, ensure that you are making recorded decisions for why you fix a defect or don’t and make sure you don’t lose them if you choose not to deal with the problem now. Integrate as you go versus waiting till the end when you’ll have a mess to unravel.  Track your technical debt and deal with it as you go rather than saving it for the end.
5. Do more than a kickoff. Do little retrospectives where it makes sense assessing what to stop, start or continue doing to make the project run better with the team. Document these and  reuse them on your next effort.

“When project management isn’t your whole job, how do you keep it from taking over your whole day?”

Let us all just accept that no one is good at multitasking. We can do it but it means we will work slower at everything we are working on. This goes for the team and the project manager. Ideal is one project per team member. Doing one or two projects can be done. Anymore and you  are going to be shooting yourself in the foot. The cost in changing focus will burn out your team and make their work suffer.

For the project manager the ideal is managing the project and having the rest of your work be relevant to that same project or projects. Let’s you focus and work deeply.

Doist’s article has a good suggestions in it but there are some fundamentals that would increase their effectiveness quickly.