People : Keep remote teams involved.

Development teams away from the head office normally feel left out of what is happening . They feel left out of the loop even if nothing is actually happening. I have worked from our company headquarters and from remote locations long enough to realize that you will feel that way when you are in a remote location no matter what your position is. There are a few things we can do to mitigate such feelings. Instead of broad suggestions, I'll talk about the things that we do with some degree of success.

Remote Project and Production Managers feel that enough information is not reaching them at the right time to enable them make their execution plan.
1. Online CRM applications like Salesforce.com can address these problem to some extent. Give access to your CRM application to your production managers and remote functional managers so that they know what projects are coming down the pipeline. You don't have to be a Fortune 500 company to have Salesforce.com or other online CRM applications. Small companies can afford it with very little capital investment. Most online CRM application provide a pay per use model.

1a. If you are part of or manage a distributed team, one way to share information with remote team members is to post your meeting minutes [or chat notes] in a collaboration tool like Sharepoint. This not only makes the information available to others, but also allows them to add their thoughts and comments [if they have the rights to do so] to the minutes. Some of us may argue that we can do this by email. While email is very effective, it is still a communication tool. I have seen teams use email to collaborate but I believe that online collaboration tools are more efficient and serve the purpose better.

1b. Content development teams and professional services teams that need to work together closely to deliver a product can benefit from document sharing systems like WorkSite from Interwoven. Such systems allow you to store documents, version them and share them with remote team members online. Teams spend a lot of time asking each other about documents and such systems can eliminate waste of time and improve quality and efficiency.

One of my colleagues, Brunda, once emailed my team inquiring about a few blueprints my team members wrote for some of our customers. It took her about 5 emails and about 15 days before she could get those documents. My team mates are normally very responsive, respectful of each others time and prompt in their actions. However even such a responsive team took a lot of time to respond to such requests because of other pressing customer requirements. Brunda probably did not feel well supported and probably even felt ignored. We wanted to correct that and give our content engineering and quality engineering teams immediate access to all blueprints we write.

We then moved all our documents to a document management system. All employees of the company have access to the system using their corporate login. [This is important because they dont have to remember another password]. We have clear direction in our site about where to look such documents. I hope that this has improved our credibility with our distributed teams. Since we made this site available, I believe our engeineers have realized that it is faster to go to this location and check for blueprints rather than email us and wait for a while.

The system also shows us a history of all the documents. We now understand who uploaded the document, who viewed the document and when they did so. For example, if i send the link to an engineer and if he keeps asking me questions that are answered by the document, I check to see if he saw the document. If not I persuade him to do so.

• I want to mention that enterprise systems like WorkSite, and Documentum are fairly expensive and require careful consideration and a big budget.
• You may have to work on changing people's behavior before such systems can become useful. If you keep emailing your documents back and forth, users will never be encourgaed to go to the online site. We are still working on our sales teams.

2. Get the development managers involved in the Sales Proposal or Design review process. The very fact that you asked them and respected their thoughts will increase your credibility with them. You may be surprised by the amount of knowledge and skills they can bring to the table.

3. Nothing can replace face to face communication. Plan and budget for functional and production managers to travel to the headquarters and customers sites. You will spend the money any way. It is a question of doing it proactively and creating opportunities versus spending the money to fight fires.

Some inputs to team members in remote locations:
1. It is up to you to access information from the appropriate portals of the company. Find out which are the useful portals to go to. Develop a working relationship with one or two people in other teams [the sales team or the consulting team] so that you can get a personal point of view.
1a. Demand teams and consultants need the help of design and development teams all the time to make the sale, build prototypes, demonstration, understand products etc. So it can be a mutually beneficial relationship.

2. Sometimes you are not involved in what is happening because probably nothing is happening.

Defining Work : Break it down

If web or training content [and I believe even software and other products] is to be developed from several different places by people who probably have not met each other face-to face, it is important to break content down into small manageable chunks. John Van Dreser, a colleague of mine, introduced me to the concept of breaking design and development work into work packages that are more or less uniform in size, in terms of development effort.

We broke work down into small chunks and called them work packages. We defined a work package based on the effort involved, the skills involved and the value it delivered. So when there we started a Project, we broke it down into several assignments, broke assignment down into several tasks and broke tasks down into activities.

When a person requested for work, they defined what the work is in terms of the above mentioned terms. Over a period of time the usage of terms diminished and the protocol was tacitly understood by most team leaders. Several others simply followed. Every work package when requested was given a unique id and team's refered to the id when they requested for work.

Estimate the effort required: When a project was broken down into activities, we could attach a work effort with every activity. Since learning content development was not as clearly defined as say - assembling an automobile, we used a simple approach. We found out what the total price of the project was [based on what the market was willing to pay], reduced the profit margin from that and calculated the number of hours available to develop the content.

Different team members such as Instructional Designers, Visual Designers and Content Integrators were them informed about the exact number of hours that were available to them to complete their work. It did not work perfectly all the time. However we recognised the areas that need some sort of automation or special attention.

Caution: Not all team members care about profitability of the company [as ironic as it may sound]. While all of them have the right itentions not all of them have the right know how to run a project profitably. This aspect will require special attention by leaders at the top.

Do we need a online system or software installed to follow this? No. The protocol is independent of any software or system. It is a simple, commonly understood development discipline that needs to be communicated to everyone and understood by everyone.

However, after a few months of using the work package protocol and once the behaviour change was accomplished, we did build an online system that enabled people make these requests from an online form rather than use a word document and email it. There were different forms for different types of work and every type of request and all forms clearly stated what inputs are required from the requestor for the job to be completed effectively. Technology enabled current behaviour. It did not drive behaviour change.

The initial system which did not store or track the information was build using Java Technology in about 10 person days. It was recognized as a useful tool and a 2 member engineering team expanded it with backend database and tracking in about 30 person days. The effort we saved using this system will definitely be several times the investment of time. Once we grew in size we discontinued the protocol and went back to doing things the old way. However, other communicating improvements like cheaper conference calling and freequent meetings made up for the same.

Defining Work : Protocols

I worked with several of my colleagues, especially Prasad Bartakke, to arrive at a set of development protocols that we need to follow if we were to deliver our projects on time. We referred several books and drank several glasses of milk [yes milk] over weeks before we arrived at three basic development Protocols. Prasad Bartakke has a structured thought process that helped us define these protocols.

We defined three protocols
1. Communication Protocol : How to use various communication mediums and types to get the job done effectively.
2. Work package Protocol : How to request others to deliver work and how to respond when others request for the same.
3. Responsibilities Protocol: Who is accountable for what.

The first two worked out very well. The Responsibilities protocol did not work very well. I'll elaborate on these protocols later.

Some of the books that helped us in those days are Rapid development by Steve McConnell and "Debugging the Development Process" by Steve McGuire. Even though these books were written by Software Development managers, we were able to adapt many best practices to learning content development. Both books were fairly pragmatic in their approach and helped us very well.

Tools: Communicating Beyond Text and Images

I spoke about using online collaboration tools such as WebEx, Live Meeting and Breeze Live to share documents, whiteboard, drawings etc. If your teams are globally distributed and you would like to share the minutes of you online design discussions [perhaps with a customer] with them, there is a very effective way to do that.

Most online collaboration tools allow you to record the sessions and save them as a file. After recording you can share those files easily by placing them in a web location [or email or ftp] so that remote teams can get more comprehensive information than what text and pictures can provide. Such recordings communicate the context of the discussion and decisions taken better than writen documents. More over such recording will significantly reduce the need to write very detailed discussion minutes. The recording can be made available a few minutes after the discussion unlike meeting minutes which will take a while to write.

The tools you need: To record an online session along with audio from your phoneline, you need a PC-Telephone adaptor. I use the PC-Telephone Adaptor from Dynametric. It costs about $100 and has worked well for me. The adapter connects to your PC and Telephone. It works fine even if you use a head set.

Tools : For Online Design Meetings

When you have designers and developers working in different locations of the world, you need more than text and voice communication. In the early days many companies went overboard with this idea and started using video conferencing as a means to do this. That was simply not practical because of the high cost and bandwidth requirements. Plus, it had the same problems of getting a conference room [in some cases in buildings away from your office] and getting people to get there on time.

What was really required was a way for designers and developers to share their ideas through pictures, documents and whiteboards.

The online collaboration tool from WebEx worked very well for us. WebEx has a good model where coporations can buy the service and employees dont have to worry about the costs. Meeting hosting rights can be given to select individuals.

WebEx also allows us to record a presentation along with the phone conversation. I'll talk more about the tools required to do that and how you can benefit from it later.

There are similar services such as LiveMeeting from Microsoft and Breeze Live from Macromedia. I have used them a few times. I believe, any of these will serve the purpose very well. WebEx and LiveMeeting have a free trial period.

Tools : Document and Information Sharing

We used new technologies to collaborate online with customers . Initially we created extranets [secure web sites that only you and your customers can see] to share documents with our customers. It saved a lot of communication time, avoided unnecessary email chains and presented a organized information map of what was going on in the project to the customer. Almost all projects teams have a customer extranet today. However most teams have a web site that is managed by one person.

One of my team members, Mike Phyle, used to manage our extranet. That was not his primary responsibility and project managers had to wait until he had the time to post content to the site. In 1999 one of our project managers made a distress call to me and said "Can you get a system that allows me to post the documents myself without waiting for Mike". I promised her that we'll get a system like that without any idea what that system would be.

We then found out that Sharepoint is packaged free with Microsoft Frontpage [Costs a few hundred dollars]. We used Windows Sharepoint Services to share documents and meeting minutes with customers. We used an internal installation for a while and decided that it was cheaper and more efficient to use the Hosted service that microsoft provides from its small business web site. They do a pretty good job with that. It is pretty inexpensive too if you have about 25 customer projects at a given point of time. We used it for more than two years before we moved to an internal enterprise system.

Tools : Instant Messaging

In this post I plan to share the various tools that we adopted early on. Some are mainstream tools today, but some may be still new to some of us.

Instant Messaging: Most development teams I know of like to cut across rigid processes and collaborate freely. Around 1997, we were using phone and dial up email to communicate with designers in the US and our across our development offices in India. It was very expensive to make international calls and dial up email upload was done only periodically.

One of my colleagues, Deepti then told me about a messaging software that we can use to instantly communicate across the world. I asked her about the cost and she said it is free. It quicky spread across the company. We set up formal chat meetings and I believe that it made us very productive and cut down our communication costs to a great extent. AOL Instant Messanger allows you to create a link for a chat room and post it to a web site. It makes it convienient for every one to go to a web page, click on a link and join a chat room rather than wait for a chat invite. It is similar to a telephone conferencing system. We posted the agenda for the meeting on that web page with the chat room link. It ensured that everyone has a chance to see the agenda. Here is a sample link. Click here to see how it works.

Chat Protocol: Unlike normal web chat rooms which were mostly unmoderated, ours were very well moderated. The interesting part was that it was moderated by some of our youngest team members and they did a wonderful job keeping the meeting focused. For some reason they were more comfortable doing it online compared to a face-to-face meetings.

We wrote a chat protocol [not any new technology..just a document] and informed everyone about the same from the same web page where they came to join the chat.

One of our Project Managers from our San Diego office, Vicki, was a bit skeptical and wondered how a chat tool can help us at work. I helped her install the software on her machine so that she can overcome her doubt. A few weeks later she became a power user and enjoyed the convienience of instant messaging very much. One of our VP's was very enthusistic about it because it allowed him to reach employees one-on-one no matter where they were in the world more efficiently than a phone call.

About a year after we started using instant messaging as a formal communication medium which everyone including, directors and VPs used routinely, The Wall Street Journal wrote an article about how instant messaging would help business.