How to Start a Web Development Project with a Remote Team

Starting a project with a new client is a lot like starting a relationship: you went on a few dates and you definitely like each other, but you are still distinct people with a different background and you have to be sure you agree on some fundamental things to make it last. Otherwise sooner or later these dissimilarities will haunt you and the beautiful thing you had together.

Fortunately, it's much easier to achieve in web development than in an interpersonal relationship, so in this post, we want to talk about some things you would want to pay attention to before diving into the new project. Some points might seem obvious but it doesn't mean they are not worth discussing, just to make sure all the parts have the same understanding of "obvious".

First of all, just like the real date will give you much more insight than an online chat, workshops on-site are always more effective than any number of calls. It relates especially strongly to remote teams, when (and it happens very often) development teams and the customer are separated by thousands of kilometers, and meeting each other in person is a great asset for both sides. And even if the distance is not that huge and your offices are next door, few days of observing each other's work and intense discussions will tell you more about the details of your future cooperation than all the contracts and emails.

Not to mention that it's just a side effect of a really productive brainstorm on design and/or scope defining where a project could be evaluated from different perspectives. It's also where business values are clarified and both sides can make sure they are on the same page with the project's values and goals. In the end, it saves a lot of time and misunderstandings, which in turn directly translates into the project's budget and timeline.

Such workshops, of course, require certain effort and time (as every trip planning does) which is not always possible to spare. This doesn't mean the "let's agree how it will work so we all benefit" discussion shouldn't happen. It's always worth having a call with all interested parties and people who will be working on the project soon.

So what are the aspects you should definitely talk through while establishing the details of the new project? Well, we can divide them into three bigger categories, where the first is:

Communication

Time zone

This one seems pretty obvious, but nevertheless worth a discussion. If your client is based abroad, make sure you will agree on the time of the calls/standups/reviews upfront, so it will suit both teams. Even in the case of a domestic customer it makes sense to discuss your companies' policies about working hours - you can have different expectations about response time and it's always good to set some rules (or exceptions).

Channels

Skype, mail, Hangouts, Slack, Hipchat, cell phone, Lync, Jira, Basecamp, pigeon mail, sticky notes - there are plenty of ways to communicate these days and you can't expect another person to be totally aligned with you by default on which is the best one.

Quick example: the customer Alice has an urgent question for lead developer Bob and addresses it by Skype (since it's a natural way for her to quickly reach out to someone) and Bob, in his turn, hasn't used it on a daily basis since 2010. It stays in his tray muted because he doesn't like to be distracted and he expects all important info to come to him by email. At the end of the day Alice feels ignored and asks Bob to turn on Skype. Bob is now distracted and his velocity drops.
  

It will save you time and nerves to agree which channels of communication are preferred and for which purpose (for example new feature requirements only arrive by mail, so nobody will miss it accidentally). That doesn't mean those rules shouldn't have exceptions, just all the parties should have a clear understanding of the common grounds.

Contact person(s)

Simple. Important. Polite. Write down who will be responsible for what in your project (e.g. infrastructure, scheduling, business logic questions, etc) and share this with all the stakeholders - that will guarantee that all the questions will go directly to a person capable of handling it instead of being bounced around via email for days.

Introducing the team

Last, but certainly not least - it's important that everybody knows who they are working with. It's pretty straightforward for internal teams but often skipped for the customer's or another department's teams. Be sure to introduce all the participants to each other along with their roles, responsibilities and contact details. The reasoning behind it is very easy - it's much more pleasant to work with someone you know, especially if you've met personally (which is another strong argument for onsite workshops before kickstarting a project).

Moving forward to heavier stuff...

Infrastructure

This section mostly contains technical aspects of development, and not all the customers want to actively participate in this discussion, some would rather trust their partner with it. And as anyone will tell you, trust only works when all parties are aligned with what they want to get in the end: under all the technical details lie the business needs and processes which the customer knows best. So even in the case of a not-very-technical client, these decisions should be well understood by both sides and taken together to make sure everybody moves towards the common goal.

Instances

First of all, define what kind of environments your project (and the future app) will have:

• do you need an environment for internal testing?
• do you need a preproduction instance for user testing or customer acceptance?
• how should they be configured?
• will the application need a sandbox environment for the support of released features?
• would there be a migration needed and how should we prepare for it?
• who will host all of it?
• what OS do they use?
• who will support the instances?
• or would it be cloud-based?

That's a lot of questions, but most of them will influence the rest of the processes directly, so they have to be figured out as soon as possible.

Technologies and third-party software

Most projects have core technologies agreed upon upfront, before deciding on the specific team to implement it. However, there are always things we see as less important for this major decision and it's essential not to leave them unspoken at all.

• Have you decided which exact versions of your core techs will be used in the project and checked if they are compatible with any third-party services you plan to use?
• Yes, and by the way, which services would those be?
• Do you have all the external API specs ready (or at least the idea of their design)?
• Do they require a license?

This list could go on and on since it touches the requirement specification process that lies far beyond the context of this post, but what you might want to think about are things that do not directly depend on the dev team or the customer: new services or browser releases during the development timeline, existence of support for specific libraries you plan to use - most of the things will be easy to replace by an analog approach, but it's worth it to check with your teams.

Accesses

When the general setup is defined, it's vital not to forget about roles in the team and their accesses - it saves a lot of time when done before somebody desperately needs it. Think of environments you will use as well as the external services - who would set up the accounts and how would you share them, how would you store and distribute the credentials, if a new person joins the project where can they find all the necessary details, and so on.

Processes

This is a difficult section since most of the points here could be easily expanded to be separate posts as there's the whole science behind them. We'll try to just touch the surface of what a Project Manager should focus on giving the discussion a direction and making sure that those points are out of the grey area.

Git workflow

In most cases, setting up the flow for the development process is not the responsibility of the PM. But as experience shows, taking part in setting it up and having a very clear understanding of how it works helps to identify and prevent a lot of issues in the future life of the project, so it would not be wise to neglect it. Also, the customer should understand the specifics of the process for it to be transparent, e.g if you practice code review, that should be discussed upfront. Though it gives an advantage in code quality, later it could cause certain delays in delivery, and such questions should be talked through before it comes to necessity.

Design process

If your project includes a design phase, be sure to define what the definition of ready should be and how the sign off will happen.

Quick example: the customer Alice received the designs of the feature from designer Eve by Slack, they discussed it a bit and Alice said that she likes it and totally agrees with the content. Happy and proud Eve sends it to the development team and they start to implement it.
    A week later Alice comes back with the feedback from her sales team which contains major changes in the functionality. Slightly irritated Eve realizes that designs could not be counted as ready until they are signed off by the customer's sales team, and severely upset developers have to start from scratch.
  

Seems obvious as well, but companies' processes of making design decisions vary a lot, so it's better to be prepared.

QA process

Doesn't matter if the QA process will happen on the developer agency side or the customer's - there are still few things to clarify before you start:

• how to report bugs,
• how to set priorities to the freshly discovered ones
• how would they be treated. (The same question goes to the UAT phase if one is planned.)

The internal life cycle of a feature

When the details of the sections above are more or less defined you can shape the flow in which feature should move on its way to readiness. This will usually result in having a Jira/Trello/etc workflow which will be used by everybody involved in the project. The life cycle of the feature plays the role of the skeleton for the whole development process. It will be strongly connected to the infrastructure choices, the processes you defined before, and the team that will be working on it. It definitely requires thorough thinking, discussing with the team, and taking edge cases and disaster scenarios into consideration. What can be done at this stage is to make sure that both the team and the customer understand this flow and realize that disrupting it will most probably result in more of a mess than provide a real advantage.

Responsibilities on both sides

Don't neglect the obvious questions like "who will make sure the requirements are complete?" or "who will make a final call if the feature is ready to go live" or "who will wash the dishes?". It saves time when it's clear from the beginning who should take care of what in the project.

Methodology to use

Unfortunately, Scrum is not the universal answer to all problems. The general approach that will be used to manage the project strongly depends on the project's needs. This point is a much wider topic than this post can possibly cover (but soon another one will!). On a side note, your final choice on this one can influence the type of contract you are going to sign with your customer. (We have recently published a blog post on fixed price vs time & materials that explains it in more detail).

Summary

As a conclusion that has to be said, going through this list before starting the work on the project doesn't mean that these things shouldn't also change during it. They can. And they will. And there's not much that can be done except to constantly analyze and adjust. Every new project is a bit different from any previous ones and with each of them, you have more knowledge, experience, and skills. And yet, the next one will bring you new challenges and new ways to solve them.

So the key to having a long stable partnership lies in being constantly aware of its needs and threats, sensitive to arising problems, a readiness to compromise, and having trust and transparency between parties oh, wait a minute.

Peace, love, and don't forget to check browser support!

P.S. If you think that we might have forgotten to mention anything crucial with starting a new project let us know in the comments section. Let's learn from each other!