Category Archives: Game Production
Milestones and Glass Houses: Protecting Your Development Schedule from Shattering, Part 1

It’s a pathetic scene all too common to game development. A week’s worth of pizza crusts and coke cans litter the office. Artists and junior programmers nod off in their cubicles, exhausted by a stretch of all-nighters. The project leader paces back and forth, annoyed that the game is long past schedule and worried about whether money will come in time to make the next payroll. Throughout the day a dozen pairs of angry eyes bore into the back of the lead programmer, who continues to plod on. Finally, he turns to face the rest of the team and nods wearily. Now begins the upload of the build to the publisher, a several-hour process that will get the promised delivery to the publisher at 3am on the day after it was due. The next day, the project manager telephones a dozen times before getting in touch with the publisher. The news is not good: the game won’t run and a new milestone will have to be submitted.
As a game producer and former programmer, I hate having to reject a milestone. I have too many painful memories of living the hand-to-mouth existence of a poor developer, having to beg a publisher for speedy processing of an advance check. So, as penance for all the milestones I’ve rejected in more recent times, I’ve written this paper. It looks at the process of developing games funded by publishers through milestone advances, the many reasons why milestones are rejected, and what
Great Expectations
“I want to fund your game,” the Big Money Guy tells you after your pitch your game idea. “But only if it can be finished in time for next Christmas. And I want it done for a reasonable price. Oh, and I want it to be a hit.”
You flinch at first. Then you summon up your confidence. “No problem!”
But there is a problem. A big problem. You’ve doomed the project even before it’s begun.
It is possible to make a game quickly. It is possible to make a game cheaply. It is possible to make a game that’s great. The problem is that you can only achieve two of these goals simultaneously. To make a great game quickly, it will cost a lot of money. You’re going to have to pay top dollar for a large and experienced development team, the best hardware and software, and extremely talented project management. To make a great game cheaply, it will take you a long time to find bargains on people and technology. But a cheap game made quickly will likely be a flop because it will be competing against games that had more time and money lavished on them.
Game development is a marriage of technology and creativity, and these two elements add a high degree of uncertainty to the project’s schedule and budget for the following reasons:
- The programmer is often called upon to invent new algorithms or techniques during the course of the project, and innovations are difficult to predict.
- Technology changes so rapidly in our industry, it is often necessary to make unanticipated course changes in the middle of development.
- Creative people sometimes suffer from writer’s block or artistic temperament, their productivity unexpectedly dropping for stretches of time.
- Talented developers are in high demand, and their availability is dependent upon what other opportunities are open to them.
Still, many businessmen can’t understand why it is that experienced developers can’t make products that are on-time and on-schedule. After all, they argue, many creative professionals are required to perform while sticking to a schedule. As for technology, the Apollo program had to schedule the invention of new devices and materials, and we still managed to land man on the moon on time. Therefore, businessmen conclude, you ought to be able to do the same with software.
And you know what? They’re right. Many developers (myself included) started out as teenage kids in a garage operation with a “let’s put on a show” mentality. Our industry is still quite immature, having yet to acquire the discipline found among other professionals. While creating a product that’s good, cheap and fast is an extremely difficult task, the difficulties are not excuses for sub-standard work. There are many techniques and practices we can adopt to improve our performance.
Skill at putting together a realistic budget is a good example. If you underbid a project just to win a contract or you put together a budget without factoring in all the details and contingencies, the people funding the project may hold you to your original budget. Somebody’s going to wind up putting in a lot of long hours for free. On the other hand, if you bid a project too high or pad the budget, you run a gamut of risks from having the project be canceled to being sued for fraud. Developing games is not a hobby; it’s a serious business that needs to be treated as such. Game developers must exercise good business sense.
But let’s not let the Big Money Guys off the hook too quickly.
Many businessmen exert tremendous pressure on the development team from the start to be on-time and on-budget. However, deriving a development schedule to meet business needs rather than basing it on the actual time it takes to develop a project leads only to self-deception and disappointment. To add insult to injury, when the Big Money Guys are pinned down once the developer is out of earshot, they will admit that it is much more important to have a game that’s of high quality than one that was on-time and on-budget.
The truth is that you need to have someone pushing for the project being on-time and on-budget, and another person being a champion for the game’s quality. Both objectives are necessary to achieving an appropriate compromise. You need to be aware of your time and money limitations when you begin a project, and you need to be realistic about what you can accomplish within those limitations.
Sprinting over the Waterfall
Of course, there’s always the agile approach, which has gained popularity within the game development community in recent years. Agile project management sees development as an iterative process, in which the project is developed in stages (often called “sprints) of several weeks duration, at which point the project is evaluated at the end of each stage, and development goals for the following sprint are determined. This differs from the more traditional approach, called “waterfall”, where the goals for each stage are determined at the beginning at the project, usually before the project is being signed.
The agile approach has several advantages. The development team can more easily respond to changes requirements, such as when the publisher sees that the finished result is not what they had in mind, or when play testing reveals that the game is not as engaging as it should be. The end result, in theory at least, is a high quality game developed in the least possible time and having a satisfied client.
Unfortunately, this process is very difficult to manage if the participants on both sides are not experienced in agile project management. In a large or technically complicated project, it may be very difficult to assess the effort required to get the initial sprints to produce deliverables that are substantial enough to show a good vertical or horizontal snapshot of the overall game and provide enough information to determine what the goals of the next sprint should be. And if the publisher is not skilled at reviewing early prototypes, they may not provide clear direction for what they want as the goals for the next sprint. This can result in the project getting off-track and consume much more time in additional sprints than originally planned.
Some projects employ both models. The waterfall approach is used to develop primary milestones such as proof of concept, first playable, alpha and beta so that the project can adhere to agreed-upon overall schedule. The agile approach is then used for new features or feature changes so that they can be implemented rapidly.
The Best Laid Plans Of Milestones And Men
For a developer to determine what he can accomplish within his time and budget constraints, he must come up with a plan for how he is going to create the game. The end result of that planning should be a road map of specific steps that the developer needs to take to create the game. Such steps become the development milestones, the safety points at which the publisher doles out advance payments to the developer.
The milestone payment method of development offers several advantages to both the developer and publisher:
- It is an objective means by which both the developer and the publisher can measure progress. However, milestones need to be written in such a way that a third person can read the milestone description and determine exactly what the milestone should accomplish. It also helps for the developer to establish procedures to help the publisher determine that the milestone does exactly what it’s supposed to do. An excellent place to include such procedures is in a technical design document created as one of the game’s first milestones.
- It provides interim goals for the developer, helping him to focus his efforts. Developers should prioritize tasks so that they do the most important tasks first. If the project is technology-based, completion of the game engine should be one of the earlier milestones. For games primarily driven by art, the initial milestones should involve storyboarding and approval of art direction. Scheduling the difficult milestones to be early in development allows both the developer and the publisher to project the completion date more accurately. Just be sure to build in time at the start of schedule for experimenting with new techniques, as well as time at the end for debugging and polishing.
- It alerts both the publisher and developer to problems early enough for them to correct the problem or re-evaluate their participation in the project. If the project is determined to be jeopardized, it is best to terminate it quickly so that everyone can get on with their lives and move on to more profitable ventures.
- It allows the publisher to invest money into the game gradually, minimizing his exposure should the project suffer problems. Weighting milestone payments toward the end of the project best does this, although it does place an extremely heavy burden and risk on the developer, especially if the game is canceled before its completion.
Unfortunately, some developers with whom I’ve worked did not take such planning seriously, which was obvious by the very terse technical design documents they created at the start of the project. They apparently thought that, with the difficulty of predicting creative and technological inspiration, with so many details being discovered or changing during development, how can anyone possibly come up with a plan that’s worth the paper it’s written on? Why not just design as you go?
Such thinking misses the point entirely. As Dwight D. Eisenhower was fond of saying, “In preparing for battle I have always found that plans are useless, but planning is indispensable.” Taking time to create a plan has the following benefits:
- It creates a clear, well thought out vision for everyone to follow. The people who have a claim on creative control (director, writer, producer, designer) need to share a common vision for the project, or they will be working at odds with each other.
- It helps the developer to consider all the necessary factors and make informed ongoing judgments. If a developer deals with problems only as they occur and fails to have any contingency plans, he is guaranteeing that the project will go over time and over budget.
- It demonstrates to the publisher that the developer has seriously considered all aspects of the process. Building confidence between the developer and publisher early on will help minimize problems that will surely come down the road.
“But wait!” you say. “If it’s so important to carefully craft milestones that will guide the developer and the publisher through the project along the safest path, then why are most milestones written into the contract – before the developer has had proper time, resources and funding to analyze the project?” That is a conundrum, all right, but there are ways around it available to both parties.
The publisher has a strong interest in having the interim steps of the game’s development delineated in the contract. Should it ever be necessary to cancel the game, it is easier from a legal viewpoint to determine how far along the project was and what each party’s remaining obligations are to each other. However, some publishers create two agreements for each project – one agreement to develop the project up through the design, technical design review, and creation of development milestones, and a separate agreement to develop the project from that point onwards. Thus, the publisher keeps inherently flawed milestones from being put into the contract while minimizing his exposure should he have to cancel the project.
If the publisher won’t enter into such a two-stage development agreement, the developer still has some recourse should he discover that his initial milestone schedule is flawed. He can amend the contract with a revised milestone delivery schedule. Both parties must be agreeable to revising the contract, of course. But if the developer does indeed have a compelling argument for changing the milestones, then it would be of mutual interest to make such a revision.
Alpha, Beta, and Gold
Everyone in game development knows what the difference between an Alpha, Beta, and Gold milestone is, right? Wrong! There have been far too many times in my career where I’ve been assigned to manage a project that is in mid-development, only to discover that the definitions of the Alpha, Beta and Gold milestones where poorly defined in the contract, and when it came time for me to deliver the milestone, the client had a very different (usually much more stringent) idea for what was acceptable than what I had targeted.
Not too long ago, I was assigned to bring to completion a project that another producer had started, and as I was preparing the Alpha delivery, the client told me that they expected the Alpha to be “complete” and “perfect” in every way. Well, to me, that’s what the Gold Master is supposed to me, but when I asked the client to explain to me what the different was between Alpha, Beta, and Gold Master was, they couldn’t. They just reiterated that the Alpha needed to be “perfect” before paying us for it, and unfortunately, there was nothing in our contract that stated otherwise.
Now, according to Wikipedia, an alpha deliverable is “the first phase to begin software testing… and can be unstable and could cause crashes or data loss.” Beta “generally begins when the software is feature complete. Software in the beta phase will generally have many more bugs in it than completed software, as well as speed/performance issues and may still cause crashes or data loss.” A Release Candidate “is a beta version with potential to be a final product, which is ready to release unless significant bugs emerge.” However, even those definitions leave too much open to interpretation.
To avoid disagreements at the critical time of milestone delivery and payment, the milestone requirements should be defined during in the contract. There are three aspects of each delivery that need to be agreed upon:
- To what degree do the game’s features need to be implemented? I normally expect that the game’s features are sufficiently implemented for testing at Alpha; and that by Beta, feature revisions are locked so that only debugging occurs afterward.
- To what degree final assets are in the game? I normally expect a certain percentage of graphic and audio assets to still be placeholders at Alpha, but by Beta, the final assets should be nearly 100% implemented.
- What level of bugs is permissible? I normally expect Alpha to have no uncircumventable crash bugs that prevent any feature from being tested, but by Beta, there should be extremely few serious, repeatable bugs of any kind.
Prepare To Submit
Would you put your money into something sight unseen? Well, you might risk a few hundred dollars on a friend’s hot stock tip. But what if it were a few hundred thousand dollars? No, of course not. You would want to thoroughly check into the investment first, which is why publishers require developers to submit milestones to them for evaluation.
Now, developers desperately want publishers to pay money for delivery of their milestones. But publishers won’t give up the money until after verifying that the milestones are what they are suppose to be. So you would think developers would do everything in their power to make it easy for the publisher to evaluate the milestone as quickly as possible, right?
Actually, you might be surprised how difficult some developers make it to evaluate milestones. Some developers submit milestones that require the installation of a specific version of some obscure third-party software, but they do not go to the trouble of providing copies of the software itself.
One trick for speeding up the payment process employed by many developers I’ve known is to submit an invoice for the milestone a couple of weeks before the milestone submission itself. The theory is that this will allow a check to be ready by the time the milestone arrives. Of course, they assume that the publisher will immediately approve the milestone upon submission. Unfortunately, that’s not always the case, as we will see in the Part 2.
Communication Tools for Virtual Teams

Throughout my career I’ve overseen development teams located all across the globe, but increasingly I’ve been managing teams where the individual members are located far from each other. The company for which I currently work is a virtual office. Those of us who are within driving distance of the main office work from our homes most of the time, and only occasionally drive into the office for important face-to-face meetings. As for other members of of our development teams, they may be in different time zones, speak different native languages, and be part of different cultures. For one project I managed, I and several programmers were located in Los Angeles, the designer was located in the United Kingdom, the artists were located in Eastern Europe, and our client was based in China.
Projects developed by a geographically-disperse team can present huge management challenges. Since project management is primarily about communication, here are some communications tools I’ve been using on some of my more recent projects.
Email is certainly the most used communications medium for virtual teams. It’s easy. It’s convenient. But it can also be misused. Here are some tips I have for using email.
- Always include a subject line and make sure it tells the recipient what the email is about.
- If the topic of the discussion changes during the course of an email discussion, change the subject line, especially if you are forwarding the email discussion to a different group of recipients. E.g., don’t keep the subject line as “Nice to meet you” if you are now deep into contract negotiations.
- Keep messages brief and to the point. Write short paragraphs, separated by blank lines. Most people find unbroken blocks of text boring, or even intimidating. Take the time to format your message for the ease of your reader.
- If your email does contain multiple messages that are only loosely related, number your points to ensure they are all read. If the points are substantial enough, split them up into separate messages so your recipient can delete, answer, file, or forward each item individually.
- Email is clunky for sending attachments, especially large ones; so only include attachments when necessary. Don’t attach a Word document to send text that could have typed into the body instead.
- Send group email only when it’s useful to every recipient. Use the “reply all” button only when compiling results requiring collective input and only if you have something to add. Recipients get quite annoyed to open an email that says only “I agree!”
My company uses Gmail as its email tool. Gmail provides each user with 2 gigs of storage space and has free IMPAP access for people who want to use more than one computer or device to check their email. It has a good spam filtering and virus protection, and integrates with other Google apps such as Google Calendar, Google Talk and Google Drive. You can pay to upgrade the free service to Google Apps for Business, which upgraded email storage, better contacts management, increased security, and mobile access. This service also less you to use Gmail with your own .com domain name, seamlessly to maintain the professional appearance provided by your own email address while enjoying all the benefits of Gmail.
However, Gmail does have drawbacks. It can be difficult to find and respond to messages in the middle of a long message thread with the way the Gmail collapses messages. Fortunately, you can use other email clients, such as Outlook, for viewing and managing emails from your Gmail account.
Instant Messaging
While email is great for asynchronous messaging, it’s not so great for real-time communications or for lengthy discussions. In a real-time world, many teams choose to use instant for daily communication.
The expected response time for responding via instant messaging is much shorter than it would be for an email. This makes quick, spontaneous back and forth conversations easier via instant messaging, yet instant messaging still allows flexibility for an asynchronous conversation – just usually a much quicker one. It is an effective way of working through a particularly thorny issue because it doesn’t carry the potential lag that emails often do. Lying somewhere between an email and a phone call, an instant message conversation doesn’t have to interrupt someone in the middle of working on something else, but also carries a sense of urgency for a relatively fast response.
Instant messaging and also improve team cohesion (informal chatter and jokes that often bring co-virtual teams together) can help provide levity and stress relief, as well as build camaraderie.
There are many free instant messaging tools available – AOL Instant Messaging, Yahoo Messenger, Google Live Messenger. These days I rely primarily on Skype because of its ability to handle voice and video chat (discussed below).
Another feature that I like about Skype is its ability to add team members to a discussion to create a group chat. A group chat that is used on a daily basis can provide a virtual office. Group chats can help make sure all members are on the same page: if things can’t be overheard, they can at least be “over read”. Even those not originally engaged in the conversation (or away from their desks) can come back to review the chat logs as a way to get caught up on what has happened in their absence. Team members that will even catch up in the evenings when they are on vacation, just to stay in the loop with the rest of the team.
Group chat can be overused or abused if too many topics are covered in one discussion thread. Tasks being assigned to someone who is not currently reading the discussion can be overlooked. To avoid this problem, I create different chat rooms for different projects, tasks or responsibilities, especially when a discussion starts to get unwieldy, and name the chat room appropriately so that members know the topic being discussed.
Discussion Boards
Instant messages are often not durable. It is not guaranteed that the person at the other end will see it if they aren’t at their computer, and if your team posts a lot of instant messages over the course of a day, it’s easy to lose track of an important conversation. This can be a major problem when, for example, having a disagreement with a client for a milestone delivery but neither party can easily find what was discussed about that matter in a chat from several weeks ago.
For text-based communications where it is important to keep a record of the discussion, I used Basecamp. Basecamp is often considered to be the best project management and collaboration platform out there. Its features are impressive: to-do lists, file sharing and storage, milestones, time tracking, project overviews and commenting. However, it is their discussion board feature that I find to be its most valuable feature.
Whenever I have a new item to review or discuss with a client, I create a new discussion thread for that topic. I then select which members of my team or the client’s team will receive email alerts when a new comment is posted on the thread. Months later, I can go back and review the discussion if there is any disagreement about what was said by either party in relation to that topic.
Voice and Video Chat
Text-based communication also isn’t great for sending confusing or emotional messages. Think of the times you’ve heard someone in an office indignantly say, “Well, I sent you email” when they didn’t get the reaction they were seeking.
Even when things are going smoothly, one shouldn’t use text as an excuse to avoid personal contact, which is essential for having individuals work together as a team.
Problems also arise when one misinterpret emotions in a text message. If you have a problem with someone, you should speak with that person directly. Don’t use email to avoid an uncomfortable situation or to cover up a mistake. When email discussion gets tense, move to a more personal touch point such as the telephone or voice chat.
Regular voice communication should be used even when things are going smoothly. When teams are co-located, that is to say all sitting in the same room or part of the office, a lot of informal communication occurs. Things are overheard in conversation that others might decide to chime in on, or side conversations might spark other questions or ideas. Also, there is a chance to let off steam and overall build a sense of team through quick conversations about interests, jokes, tools, tips, etc. These types of informal communication also serve as an important way to create a sense of team, building collective trust and improving morale.
Of course, having face-to-face communication or even voice-to-voice communication is rather difficult in a virtual office working in far-flung locations. I make it a point to schedule regular voice calls, scheduling them with geographic considerations in mind. I make my calls to Europe in the morning (when it is near the end of the day), to East Coast team members during my midday, and team members in Asia in the evening (their morning).
As for tools to use, I favor Skype. In addition to featuring text chat, Skype has become the standard for voice calls over the Internet. It’s free to use across a number of devices, including iPhones, Nokia, Windows, Mac and Linux. All Skype PC-to-PC calls are free and there are options such as SkypeOut (calling normal telephone numbers) and SkypeIn (gives you a phone number for anywhere in the world).
It is powerful to be able to chat and, when necessary, call a team member. During the phone call you can text a response that isn’t being understood due to sound clarity or language barriers. Skype also allows you to send files during the course of a discussion.
To make Skype usage more productive, you may want make sure that team members are not distracted by messages from friends. So, consider a policy where all team members have separate Skype accounts for work, and the rule to only use this account with work contacts. Also, if a text chat discussion starts going past a few sentences at a time, it’s usually faster to switch to a quick phone call and discuss thing the old fashioned way.
Screen Sharing
It is helpful to complement voice or video with real-time screens, particularly if you are brainstorming, talking about design (for example) or simply want to get on the same page faster. Also, something someone is working on occasionally needs a second set of eyes. For example, a developer may be stuck on a particular error in their local environment. Because the code change have not yet been committed to the source control system, a quick and easy way for someone else to see it is to have them actually look at that developers screen. This is easy when you can call someone over from the desk next to you; but when the team is distributed, it is not as easy.
Skype allows you to share your screen to one other user for free (to share with more than one user, you need to purchase Skype Premium). However, a tool I prefer to use for having conference calls where screen sharing is important is GoToMeeting. This simple desktop solution has been around for a while and “just works.” It is written in Java and can run on many platforms. It takes a few minutes to learn the UI, but after that starting new meetings and inviting people is straightforward.
File Sharing and Collaboration
Teams have a constant need to share files, but sending them via email or instant messaging can be cumbersome or unreliable, especially if the file is large or there are many of them. So a central repository for documents is another important tool when working with a distributed project team.
A popular and easy cloud storage solution I’ve used for the past several years is DropBox. With DropBox, you can share a DropBox folder with one or more of your team members by sending them an email invitation. To share files with those team members, you simply upload the files to your DropBox folder and the files become available to them on their own version of the folder. You can also install the DropBox app to your mobile device so that you can download only needed files from DropBox whenever you need them.
Google Drive is another tool that can be used for sharing files, including documents for detailing systems and processes the team should follow. However, an even greater benefit of Google Drive is the ability to collaborate on documents (something you can’t do with DropBox). For example, a team can use a Google spreadsheet to work through task estimates, allowing all team members to view the living document as the discussion is being held and changes are made. More than one person can contribute to the editing at the same time: one team member can be responsible for updating the estimate numbers while another makes sure related assumptions are added to the document. This collaborative way of working can add agility to the project team.
Google Drive allows you to create documents and spreadsheets that are compatible with Microsoft Office (although it doesn’t have as many features). Google Drive only takes a minute to get all of your team members editing the same document in real-time, and is free with a Gmail/Google account.
While it’s important to have places for working collaboratively on spreadsheets and formal documents, it’s also often beneficial to have a place to have informal collaborative notes. Wikis provide a lightweight, easy-to-use place to share thoughts and ideas.
A wiki is browser-based tool that allows multiple team members the ability to collaboratively create a living document, and published content can be continually updated and edited.
Wikis have many benefits. Wikis are great for brainstorming activities where all can contribute at their own pace. Wikis provide a low barrier for just adding thoughts and then coming back to build / re-organize those thoughts. Setting up, creating, and editing content is easy even for someone with no programming skills.
The ability to easily organize many pages into a hierarchy, add links and rich text all allow for a rich experience for collaborative building. The quick, single search in Wikis also makes them ideal for knowledge-sharing; and the built-in revision history and ability to subscribe to updates help keep people informed of ideas being added by their teammates.
Most wikis do not have size restrictions, and you can embed documents, images, web links and videos into any page. Because they are web-based, wikis can be accessed by team members anywhere at any time.
However, they also have disadvantages. Depending on the package you use, it may be difficult to track changes or determine who contributed a particular piece of information to a wiki page. Most wiki tools do not have as many formatting options as, say, Microsoft Word, and printing out a wiki may result in a hard copy that is long and unwieldy. I avoid using wikis on projects for a client who wants a Game Design Document delivered to them.
While you can use Google Drive effectively as a company wiki where anyone in the company is able to add any information to the document, wiki tools are features of many project management tools such as Basecamp.
Bug and Issue Tracking
Anyone with experience in game development is familiar with bug-tracking software used to report bugs to team members and keep track of whether they have been fixed or not. Such ticketing systems can also be used to break down development tasks and monitor progress on a progress.
An ability to automatically tie source control changes sets to particular tickets in your bug tracking system really helps provide a critical context for those changes. This means that team members can specify the ticket number associated with a code change, which provides a way to automatically bring up the code changes from with the ticketing system. The association helps to answer archaeological questions of why and when a change was made. Team members looking at the ticket history can not only see the full chain of comments on the ticket, but also can pull up the code changes that addressed that ticket without having to manually cross-reference.
For the past couple of years I’ve been using Jira, a customizable issue- and bug-tracking tool that includes reporting features, workflow mapping as well the ability to hook into source control repositories. Whenever a ticket is assigned to a team member that team member is alerted by email. And when that team member changes the status of a ticket, the person who originated the ticket is similarly alerted. Team members can also ask questions and comment on individual tickets as a discussion thread.
Management-Level Task Tracking
While a tool like JIRA works great for team members who are technically minded, they can be off-putting to artists, business development and marketing types. And a tool that someone doesn’t like using is not useful.
I was recently introduced to Trello, a simple and intuitive tool using a Kanban interface in which projects are presented as bulletin boards. These boards are subdivided into lists (the default lists are “To Do”, “Doing” and “Done”), and individual tasks on each list are designated as “cards”. Each card is assigned to one or more team members, and when the status of a card changes, it is simply moved to another list. Each card can have a description, due date, checklist, attached files, and/or a discussion thread. Trello has some nice features for teams including voting, email notifications and real-time collaboration.
Trello is especially well-suited for agile teams, allowing you to create sprint task lists and project backlogs. Unlike traditional “waterfall” project management tools, Trello allows a team to work on an ever-changing, collaborative, virtual white-board that gives managers the maximum amount of flexibility. The interface is robust and intuitive – anyone can pick it up quickly and organize their tasks in a smart way. It is also extremely flexible. You can break down tasks for a specific client, training new hires, working on business development or even planning your much-needed vacation.
Trello offers free versions for web and mobile devices, and a single, paid Business Class option.
Bottom Line
There are many tools out available for improving communications among a virtual team. The trick is to determine the right tools for your project and your team, and to set up rules for using them effectively. Do some research at the start of your project and come up with a Communication Plan for everyone to follow.


