Everyone does virtual differently. Having worked in bricks-and-mortar previously, setting up a virtual work system as been something of a mix of experimentation with solutions recommended by others. Here are some of the ways we manage as a virtual company.
Email is a place to lose things. We don't depend upon email for critical project communications. We have our own Open Atrium intranet set up for all of our clients. Here we post research documents, wireframes, flow charts, use cases, design mockups, questions, general messages, and the ever essential support tickets. Our clients can post, comment on and otherwise interact with all of these items, and all the archives are there for review later. No spam filters or non-inbox-zero obstacles!
What can I say? We like Skype. It's stable, it's pretty much peer-to-peer, it is very good at drilling through firewalls, it's encrypted, it stores archives, we can do conference calls, share screens, etc. That said, we are eyeing other possible solutions, including google+. The main need is to have robust real-time chatrooms, with encryption, and easy voice communications.
Like most design and development companies, we've been pretty frustrated with a lot of the project management software solutions out there. We use Liquid Planner (affiliate link), which provides ticket-level time tracking, high/low estimation, schedule and cost projections, and some nice graphs. And unlike some other systems, we've had no problems with performance slowdowns — it's a fairly consistently moderately fast web app, given its complexity. Having tried Basecamp, Harvest, Unfuddle, Freshbooks, ActiveCollab, Trac, Jira, Rally and several desktop apps over the years, I think Liquid Planner is the closest thing to the bee's knees.
We meet with the client if at all possible. We talk. We draw pictures. We point at things. We work to understand the client as best we can. This means travel, if there's room in the budget. It ends up paying off in the end through implementation of a project better aligned with the client's needs. When not in person, we communicate through Atrium.
As for amongst ourselves, we use Dropbox (affiliate link for extra GBs of space) as an easy way to share physical files that are not suited for version control. And we talk in Skype. Sometimes we'll do mark-up on artwork or wireframes, but most of the creative collaboration happens via voice. It's somehow more human that way.
Like many, we use GitHub. Can I just take a moment here to say how much I love Git? Escaping from Subversion was transformative. (Drupal.org's escaping from CVS will be even more so.) The biggest problem with svn is all those hidden folders. They're like pox riddled throughout your code, buried in each folder, lurking. Replace a folder with a fresh one and svn freaks out, "What did you do with my hidden folder, you malfeasant!" Git doesn't do this. Git is nice. Swap out things in your code and Git doesn't mind. Git loves it when you do things like that. Go ahead, swap out a folder, swap out 10 folders! Tell Git and Git says, "Got it!" Shiny!
Development and staging
Configure globally, code locally. As soon as we start the first development sprint for a project, we set up a staging server on a VPS. Right now we are really liking Linode (affiliate link) for the smaller sites and AWS for the bigger ones requiring more flexibility on resources. Each of us codes locally, on our own machines, merging our code changes with Git. We deploy committed changes several times a day to the staging server using Git pulls from GitHub, which serves as our canonical central repository. Configuration changes, with the exception of Featurized configurations, are all done on the staging site, so that we don't have to mess with database conflicts. (Bricks-and-mortar teams can all connect to one canonical database on the same network, but that just won't work for virtual teams. The latency is not just fatal, it's fatal on a mass extinction scale.) We periodically pull database backups from the staging site to use locally, so we're all referencing the same basic configurations.
The exceptions to this relate to Features and exportables. We love Features, but find that they can get in the way at times. We use them for special cases, especially when doing iterative development, where it's nice to be able to deploy code and configuration changes through version control. On the other hand, exportables (e.g., Views and Contexts) are nice ways of moving sometimes extensive configuration work from one machine to another.
Here I'm afraid we're amateurs. We have our inquiry form. We have phones. We have email. We do things the old fashioned way. That means that, no doubt, our sales process is probably woefully inefficient at times. We're not huge, not even big enough to have a dedicated sales person, so a robust CRM really does not seem to make sense — in fact, it would probably just make everything harder to manage, spending all our time trying to get the CRM to record things in ways that are findable. If you fill out our inquiry form, or call us, or email us, it's we at the other end who are fielding your inquiry, no salespeople or account managers. Consider it the personal touch.
Drupal community communications
Anyone in the community can tell you, the ways to communicate are: on the *.drupal.org websites, in IRC, and on the email lists.
And at Drupal events!
The common thread through all of this is communication. It's not everything, but it's the most important thing.