Remote Project Management Done Right
It is no secret that companies are having trouble finding suitable developer and designer resources in the tech world. This applies to you whether you’re a bootstrapped startup, a well-funded startup, an SME or even a giant MNC. When you have no one to hire within your network, the alternative to keep things going is to look offshore. For the past 4 years, I’ve worked in startups, MNCs, SMEs, ran my own design and development agency and have built many projects small to large scale regional projects. This was all done from fully remote and offshore teams.
At MomoCentral, we’ve observed how over 150 companies worked with our freelancers and came up with a list of recommended practices. This list has so far worked for most of our companies, regardless of which country the freelancer is from.
Hire people not agencies
Many people have this pre-conceived notion that hiring offshore means hiring a development agency located in another country. It is important to consider hiring the ACTUAL individual developers and designers themselves, for reasons stated below:
- This cuts out the project managers and lets you save on unnecessary project management/agency fees.
- It also ensures you have DEDICATED developers and designers for your project, whom you have direct contact with. Most agency developers/designers straddle multiple projects and some agencies even overload their developers/designers with more than they can chew.
When you’re hiring an agency — the agency is the one doing the managing, and will naturally tend to look out for their own interests — indirectly charging you for it too. When I mention remote, it means we never had an office and all communication was done purely online. I’ve not met most of the people I’ve worked very closely with for years. Yes, it is totally possible to build that sense of trust and a good working relationship with people you’ve not met. Come on, we live in the 21st century!
Use time as the billing metric where possible
Contract-based engagements based on project scope is common, but can be fraught with problems. If you plan to manage your own developers/designers, try not to settle for anything other than time-based engagements. Set start and end work times daily. This lets you know when you can quickly contact your team for discussions, updates, screenshares etc. It gives you freedom to define their workflow and also to correct any miscommunication or features that would have been missed in the original “project scope” specifications.
Our goal here is quality as well as transparency and directness. We want to know what our developers and designers are doing, not what the project manager says they are doing. Just by doing this, you’ll likely end up with developers and designers dedicated only to your project. Those who are juggling multiple projects simultaneously to maximize profits will likely drop off or reject your project.
Talk about a Timeline Estimate
A common question is, if we go by time, how do we know what to expect and when? Always ask for estimate timeline, and what to expect to see and when. This is KEY to remote project management. Most developers like to practice what we call “Black Box Development” where they will take your scope, disappear for 2 months (or make minimal contact) and appear after that with the project. This can be risky especially if the developer misunderstood your specifications. By then it’d be too late to address any misunderstandings and extensive change requests will be required, leading to a waste of time for all parties involved.
Set mini milestones that are achievable in bite sizes. This can be daily, every 2–3 days or weekly milestones. If you’re non-technical, talk about milestones in visual, laymen terms.
For example: “OK in X days by this date, will I have anything visible that I can click or tap on? What can I see? What can I expect to click on? What will just be static? What will be functional? When can I test which features?”
If you have actual design mockups, then the best would be to go screen by screen and set milestones based on those screens
It is important to also note that it is difficult to come up with very accurate timeline estimates. It is normal for timelines to slip even if it’s not intentional because it is just not possible to state everything in very minute detail at the very beginning. What’s more important is constantly knowing what’s going on even when a milestone is not met (E.g: Change requests, discussions/clarifications reveal a feature was more complex as expected).
Working with Developers
Tool 1: Code version control system
For the non-technical: A code version control system is a system that keeps every revision of code the developer has written. It not only lets you easily track what code has been uploaded at each point of time, but also gives your developers the ability to rollback to a previous version of the code when needed (or have a copy of the code online if his computer goes bust *touch wood*)! It is also an essential tool for multiple developers to safely collaborate on the same codebase without overwriting each other’s work.
Recommended version control tools: Github, BitBucket, or if you can host your own, GitLab (free and open source!)
Your role as project manager: Everyday, or twice a week, look at the code commit logs and commit messages.
- Good developers will write good commit messages that give you a good idea of which feature’s code they wrote that day
- If you don’t trust your developer, get an external developer/developer friend to review the logs
Tool 2: Staging / Development Server
For the non-technical: A staging/development server is a server where you can set up a test copy of your app/website for development and testing purposes before the website goes live. Even after the website goes live, you should still keep your staging server. This is so you can test bug fixes or new features on your test site before uploading it onto the live website.
Recommended staging server hosts: We like cloud servers like Amazon Web Services (AWS), Linode and Digital Ocean.
- This is because you can easily clone your test site into a new server, and make that your live site.
- OR, you can easily clone your live site on a new server, and make that your test site.
Your role as project manager: As each module is done, ensure they are uploaded onto the staging server.
- This lets you test the modules that are done while the other modules are being developed
- Log down all issues found / things not built right into a task management system so the developer can get to fixing it once he is done with his other tasks
Tool 3: Task Management Tool
For the non-technical: A task management tool is a system where you can upload tasks online, your developers get notified and whenever there is an update (comment, question, change of status) on any of the tasks, you will be notified as well.
Recommended version control tools: Asana, Trello, or if you can host your own, Kanboard (free and open source)
Your role as project manager: Set up a standard protocol for updates
- Column 1) Tasks assigned but not worked on yet
– Companies put their tasks here - Column 2) Tasks in progress
– As the developer starts on each task, he/she moves the task into this column - Column 3) Tasks done but awaiting QA/Feedback
– Once the developer completes the task and uploads it to the staging server, he moves it into this column. - Column 4) Tasks completely done+passed QA
– The project manager moves all passed and tested tasks into this column.
– If anything is not done right, a comment can be added and the task moved back to column (1)
Tool 4: Frequency of updates + Mode of communication
For the non-technical: As the Talents you’re working with are remote and offshore, it is highly important to ensure you are aware of what they’re working on at all times. Miscommunications are bound to happen but it is always possible to flag and address them early by frequently communicating with each other.
Recommended communication tools: Skype, Google Hangouts or Slack
Your role as project manager:
a) Establish a communication and update protocol
b) Establish contact and work hours
- Super important for transparency
- Gives you benefit of knowing when your project is being worked on
- Know when your developer is available to have adhoc discussions/brainstorming sessions
A communication protocol we use at MomoCentral goes like this:
- Start of day — Developer to update when he is starting the work day and what his plans are
– An e-mail in combination with a Skype/Hangouts/Slack message - During the day — A quick update ever 2 hours on task being worked on. If it is the same as previous update, they can reply “Task is still being worked on”
– Just a Skype/Hangouts/Slack message will do - End of day — Developer to update when he is stopping work and summary of things done for the day
– An e-mail in combination with a Skype/Hangouts/Slack message - If in between the day, you feel there are more in-depth details you want to discuss with the developer, do go ahead and schedule a conference call / start texting away :) There is nothing wrong with being too clear/detailed about what you need but of course don’t talk to your developer so much that he has no time to work on the task.
Timezone Concerns
- Most companies we’ve met have concerns about timezone issues, especially if the developer is located on the other side of the world
- Truth is, most developers are night owls by nature so we’ve found that it actually fits in with your office hours perfectly
- Else, set working hours together so that there is more overlap/contact time together
Working with Designers
Most of the steps and basic protocols of working with developers mentioned above apply to working with designers as well. Instead of repeating myself, I’ll list down the key tools/additional designer-specific advice here:
1) Set up a shared Dropbox folder
- Dropbox now has the fantastic ability to let you preview Photoshop (PSD), Illustrator (AI) and image files without actually opening the files
- Establish a work protocol where designers upload work done so far/in progress to this folder
- This gives you the ability to view all works in progress, easily see latest updates/revisions and comment on them
2) Progress Updates
- Some companies who like more interaction can ask for a screencapture/screenshare of the work in progress every 2 hours
- Companies who are more hands-off can set milestones together with the designer of when they expect to see the first draft of work
- Logo designs: Usually within 2–3 hours you should have your first set of logo design mockups (not sketches but full, colored, final-looking designs. Sketches should be done in 1–1.5 hours).
- Website mockup/app screen designs: Usually within 2–3 hours you should have your first screen (or additional screens as well). Unless you ask for wireframe sketches of the user flow for discussion first on UI and UX before high fidelity / final mockups are worked on.
3) Set clear contact hours of when the designer is working on your task
- Set clear contact hours when the designer is working on your task/project
- This gives you the much needed benefit of knowing when your designer is within reach, and more importantly the ability to do conference calls / screenshares quickly to work through iterations and changes together
- This gets you to the final output of what you like at a much faster and efficient rate
And so there you have it — a quick, easy to follow guide on effective remote project management. All the best and happy collaborating (remotely)!
