Even though there are technologies that enable us to manage everything online, there's no replacement for face-to-face communication, most especially during the first days of a project. The start is critical because:
the collaboration culture and routines are setup
and expectations are set.
Projects are usually initialised by managers who have a vision in their heads but have no time to work out the details. They leave that to their team - and the first thing we like to do in a project is sit down with them and find out what they do in their EVERYDAY working life and HOW they do it. It sounds trivial and it's tempting to think that this can be achieved through online communication but you should try it. It's hard enough to adequately describe to a complete stranger the details of your work routines and the tools you need for them, let alone do it online. It's more expensive but a consultant on the ground at this moment helping the team formulate the project details and mutually agreeing what exactly will be delivered and how it will be incorporated into their work can make a huge difference to the scale of a project's success.
This exercise has the second benefit in that it helps to tune the two parties communication. People have a tendency to underestimate the importance of cultural differences. We might all watch the same movies, read the same best sellers but we still think in our mother tongues and our culture defines how we approach a stranger or how we formulate our needs to him/her.
When we know who we're working with and what the project's aims are THEN we can start working online. Online meetings sound simple enough, right? No pitfalls to fall into there? Actually, no. There are plethora of technologies for setting up a meeting and with them come a plethora of potential problems.
The first and most common choice is a conference call. I hate to break it to you but they suck! Participants can only talk and the voice quality is low. Not only that but when you're working with people who have different degrees of English proficiency it can become even more complex. The difficulty of talking in a non-native language can cause some parties to clam up and that's the opposite of what you want. You need everyone to feel comfortable and be able to express what's on his/her mind.
The next choice of preference are free tools. Unfortunately, they use compression. They're OK for casual conversation with your buddy but when you're discussing a schematics in a small font - you'll only have a blur to discuss.
Finally, for the virtual communication globetrotter out there, those of you for who online meeting best practices are second nature, spare a thought for the noobs and first timers. The most common mistakes first timers make are:
Setting up an online meeting as though it's just like any other, ie. several people in one room each with a separate computer and mike. Advise them to mute their mikes and turn them on only when speaking or to not sit in one room. Leaving their set up as is, will in the best case result in a heavy echo and in the worst case, pure feedback noise. Let's assume you're not discussing what's new in the Sex Pistols comeback tour and that this isn't what you want.
The other common newbie error is to start an online meeting in an open-plan office. Open-plan spaces are very loud and computer mikes are more sensitive than you might think. If you're not in a quiet room, mute the mike when you're not talking.
My bottom line recommendation is simple - use a tool which at least supports voice and display sharing and don't be afraid to pay for quality, the investment will be returned many times over.
Collaboration in the 21st century
The project's been set up, we're discussing it in successful online meetings - now it just needs to be managed. All businesses run projects, running one online shouldn't be harder than any other - another no-brainer, right? Wrong. Non-virtual project management requires professional employees experienced in working within complex systems - running a project online only adds to the complexity - it doesn't take it away.
The first problem: the document and email paradigm - write a document, send it to 10 people in CC and never stop chasing the latest version. The second problem: the single spreadsheet - prepare the team a set of task lists, put them into a single spreadsheet and never stop guessing what's been completed and what's related to what. It never stops amazing me how many people are still stuck in the 20th century way of doing things :).
If this is the mindset of the project team, force them to use a wiki and online issue tracker (e.g. Confluence and JIRA). The transparency and traceability of requirements, tasks, deliverables and bugs are essential, especially when you're doing a remote project. Wiki's and issue trackers bring clarity so that at any given moment you know how much has already been done and how much work awaits you.
Finally, however sophisticated the tools that you have are, the project still needs a project manager who is capable and willing to push all the task queues and make sure that nothing is left behind and forgotten about.
Finally a word about the analytical process - which incidentally isn't only applicable to remote projects. The complexity of the contemporary enterprise environment makes the writing of a single long, analytical document - the solution design document - best practice at the beginning of all IT projects. It's not uncommon for a project to run for several months and deliver nothing but this - without any interaction between the technology and the end user.
The solution design document does need to be written but there are two risks that come with it:
the direction of the analyses can drift away from the project's initial intent and get lost in the complexities of the environment.
even when the document sticks to the point, the customer doesn't understand it because it describes things that he hasn't seen or touched.
Plus, two more free facts:
you can be the brightest analyst in the world, but you still won't be able to think through all the possible scenarios.
there will be a performance issue, because there's always more data in the final set than anyone has envisioned.
My recommendation would be :
set up a sandbox environment as soon as possible.
make users interact with it and explain it and the concepts behind it, to them in a hands-on manner.
load as much data as possible into it, as soon as possible.
This approach clarifies expectations and identifies risks early in the project. It also starts a natural knowledge-transfer. Later, when a decision or technological compromise is needed, the customer has a much better understanding of the project and the vendor-customer relationship is more equal.
What is your experience with remote projects?