Some guidelines drawn from experiences working on projects with remote partners

Posté le 29 octobre 2011 @ 11:58 par Manfred

This article lists a few hints I have learnt through years of experience working on projects with people far away, in other distant offices.

General team work

Responsibilities come with power, and vice-versa

Do you remember the old moto “with great power come great responsibilities” ? Well, it also works the other way round : if you want people to take responsibilities, you have to give the power that is needed : the power to make decisions and manage resources. If they have them not, do not expect them to act responsible, because they cannot !

Be transparent about information

For the sake of efficiency

If you want people to work efficiently, you have to provide them the right information. If you think you cannot divulge certain information, you ought to at least let them know this information exists but you cannot divulge it. This way, the day this information is relevant to make a decision, they may come to you and ask for your opinion, knowing they have not all the cards in hand.

For the sake of mutual respect

When you lie to people, they end up knowing it. And to this regard, hiding information and denying its existence is the same as lying. If you want to keep your collaborator’s respect, at least tell them frankly you cannot share such or such information. They may not agree with your reasons and not like it, but at least you will not loose their respect because you are lying to them.

Have a clear line-of-command

There is nothing worse than having several bosses who disagree or did not consult together but supposedly have authorities over the same things. You end up doing and undoing things.

Of course, on the slideshow somebody did to explain the organisation of the project, these 2 bosses theoretically have different roles and authority over different things. However, often when 2 bosses or more are involved in the same project, since many issues have consequences on many items, they all end up giving contradictory orders.

Some clever people may actually exploit the situation by playing the bosses against each other. That may be fun for the clever one, but will not be good for the project and its ambiance.

Have a clear line-of-command with very clear borders.

Remote work on a distant site

Some hints for when you are sending people to work on a distant site to achieve something.

Have a start-up kit ready

If you are going to shunt off somebody right in the middle of nowhere alone for a project, you would better give them some tools with which to start their work. Otherwise, they will loose a lot of time finding these basic tools.

Example for a construction project, that might be : a box with a printer, some fluorescent jackets, a mobile internet connection, a suitable vehicle, …

Give them the autonomy to do their job

As said before, to take decisions, you need information. That also include some information that only people on-site have. Some of it can be communicated to remote supervisors. Some of it is difficult to communicate because it is non-verbal and more “intuitive”. Even not all the information that can be communicated should be : it is time-consuming to write reports and emails, to make phone calls to explain things to people who are not there. The time they spend doing so is time they cannot spend on the actual on-site work. And that will also consume some of your time. So keep this communication to the necessary minimum. Let them handle as much decisions-taking as possible without having to ask for your call. There are often more than one single way to do something, it does not matter how they do it, as long as they do it properly. If you do not trust the people you sent on-site for taking the right benign decisions, then you have a problem, but it is a problem of casting.

On-site people are the best placed to take on-site decisions. Give them the information they need and let them take these decisions.

Use of computer tools

For good or bad, internet, mobile phones and computers have become part of our daily work. But like the rest, there are ways of using them efficiently and ways of wasting your time.


Define communication channels

If you sometimes receive twice the same information by different channels, it means that you have no clear channels defined for communicating information. It should be defined clearly who is in charge with spreading what information to whom.

Avoid forwarding

Forwarding emails in series makes the information difficult to read. When you end up having an email including 10 forwards and replies, you must scroll up and down alternatively to recompose the full story. If you must inform people of a situation they they were not aware so far, instead of forwarding series of emails, better make a summary of the situation - at least as a header of the list.

Also keep your email signatures short to avoid cluttering up the text. The disclaimers that most companies include is completely useless : professional people all already know they are not supposed to divulge the information to external parties without authorization and if they want to do it anyway, they can delete these disclaimers with a swing of their fingers on the keyboards.

Avoid ambiguous answers

An email starting by “Have a look at that” followed by whatever forwarded (un)relevant piece of information is useless : what are you supposed to do with this information ? Give your opinion ? Take action ? Only read it ?

Be clear in your emails with what you expect from the various recipients.

Give explicit titles and use prefixes

If you are working on project Dudu, and need somebody to check a faulty invoice from supplier Yepo for the delivery of 100 thingummies, don’t put “faulty document” or “mistake” as a title to your email. When somebody will search for it 2 months later in a folder along with a thousand other emails, there may be 30 emails with this title.

You could use instead: “[Dudu][accounting] faulty invoice from Yepo for 100 Thingummies

That will make searches through emails much easier and faster.

Besides, having clear email titles also saves you and your collaborators time : when you  are browsing your current emails, you do not even need to open them to know what they are about.

This rule is especially useful for people working on several projects at the same time.

Understand that some people are busy with other things than emails

When you spend your day in the office sitting in front of your computer with a high-speed connection, it may be easy to forget that some of your collaborators are not, and that they cannot answer your emails before a couple of days because they are busy far away from their computer.

If they receive 10 emails sent back and forth with comments, pointless answers (“Ok”) from different people who have nothing else to do all day but emails, it will waste more of their time.

Do the email chit-chats between people who have time to spend at it and send a summary to the others once you have finished.

File sharing

I have been working with file sharing systems for over 10 years now (CVS, Subversion, Dropbox ..). They work great, but some rules are to be followed to avoid total chaos.

Use full explicit file names and avoid abbreviations

If your team involves a lot of people, it is likely that there will be hundreds of files and that nobody will know exactly what is in all of them, so naming them properly is important.

Abbreviations work .. for yourself only. Maybe for the people sitting in the same office as you. If you are working with people from different organisations or different offices, they will often use different abbreviations and not understand yours.

The rule is : make your file names explicit enough so it is not necessary to open the files to know what is their content.

Use cross-platform open file formats

The point of sharing files is that others can use them. If they cannot, you would better keep them for yourself than clutter up the folders.

Unless you are sure of working only with people who have the exact same computer configuration as yours (i.e. in certain companies with standardized work stations), you would better choose your file formats to make sure that :

  • They are compatible with all operating systems (Windows, Mac, Linux, Solaris, Unix, ..)

  • Everybody can have a software to use them (at least read them).

PDF files are an obvious choice.

This rule also straightforwardly eliminates the MS Office files formats. I recommend ODF formats (OpenOffice) because it is available for every possible operating system and, being open-source will not require buying a licence.

If you cannot find files formats that comply with these rules, I recommend exporting systematically the faulty files to PDF. This way, at least they can be read.

For projects with a long lifespan and whose files must be used in 20 years, you may even save along with the documentation the installation files of the programs to read them and text notes on on which operating system they were made.

Divide your files into smaller ones when possible

If you are sharing files with others, that mean they may be modifying them at the same time as you are doing so. This may result in conflicts of versions and potential data loss. The risk always exists, but it is possible to minimize it by separating your files into smaller ones, independent from each others (e.g. : various sheets of a spreadsheet with no actual data connection may be spread into different files).

Define who is responsible for managing what folders

When you have dozens of folders with hundreds of files and people working remotely, it is better if - although anybody can read/use the files - you organize your folders in such a way that the management of each one of them falls under the responsibility of a single person (or a few).


Otherwise you will likely end up with a big mess that nobody understands because nobody organized it.

Clean-up !

Almost all file sharing systems offer the possibility to restore deleted versions. So clean up ! Do not keep old versions of your files in the shared folders : they will also clutter up the folders of other people.

When I really want to keep old versions, I simply put them in a sub-folder called old versions. That is clear for anybody who opens the folder.

Avoid making duplicates

One rule of data management is to avoid making duplicates of the same data. Having duplicates is the best way to end up with incoherent data sets (due to incomplete updates of the various copies of the same information).

The best way to avoid this is to have a single copy of each data. If you cannot, state explicitly what is the master version (and where it is) wherever you have copies of the data.

In what language ?

The not-so-easy-to-answer question. Sometimes there is an obvious choice, but often you have to take in account :

  • The necessity to create the project’s documentation in one of the country’s official languages.

  • The language that everybody understands in your teams.

  • The language that the people who will have to use the documentation later will be able to understand.

Generally speaking, it may not be possible to use a single language. However, you should always try to reduce the number of languages used in the documentation to the minimum.

Pas encore de Commentaires

Vous pouvez être le premier à laisser un commentaire!

Désole, les commentaires pour cet article sont clos pour le moment.