Sunday, April 03, 2005

Building the Right Software Requires Effective Communications

I recently viewed a vendor-sponsored Web cast on global software development. Despite the vendor perspective, I found the points that the panelists made very relevant.

Whether development happens onshore or offshore, whether it's done internally or outsourced, it's not so much about building software right as it's about building the right software:
  • 30% of all development costs are the result of re-work. (Forrester Research)
  • 70% of all re-work is the result of poor requirements. (META Group)
All software projects require common understanding of the business goals, business requirements, functional/technical requirements, architecture, acceptance criteria, and changes. Establishing and maintaining this common understanding throughout a project requires constant attention and discipline, and above all, it requires great communications.

Building the right software is more difficult when teams are far-flung, due primarily to communications challenges related to issues like time, distance, and to a lesser degree, language and culture.

While there is no magic to effective communications, there are some best practices to keep in mind when working with global development teams:
  • Use multiple channels
  • Have a plan
  • Engage at all levels
  • Be constructive
Use Multiple Channels
There are a rich set of tools and practices available to teams that have to collaborate across great distances:
  • Phone calls
  • Conference calls
  • Video conferences
  • Email
  • Instant messaging
  • Shared whiteboard
  • Written requirements documents
  • Diagrams
  • Static screens
  • Functional prototypes
  • Visual simulations (the vendor that sponsored the Web cast sells a product that enabled visual simulation)
  • Face-to-face meetings
Choose the right channel to communicate the information based on the situation. For instance, if the information is very complex, it might not make sense to have a conference call or use instant messaging to share it. Perhaps a shared whiteboard session would make more sense, if the situation is urgent. A written document might make a good follow-up to a whiteboard session, or if the situation isn't so urgent, it might be sufficient by itself. Really complex information might warrant a functional prototype or a visual simulation.

The Society for Information Management recently sponsored a study called Deploying Far-Flung Teams: A Guidebook for Managers, which noted that face-to-face meetings should generally not be relied upon for project delivery tasks, as getting in the same room tends to become a very expensive and unnecessary crutch for far-flung teams. They cite several examples of far-flung teams that delivered results well above expectations on extremely complex projects without ever meeting in-person.

That said, one commonly noted best practice for offshore outsourcing is for the client to have a permanent on-site presence at the vendor's project delivery location. Many vendors also like to have a permanent on-site presence at the client's location. I have found both practices to be incredibly valuable in establishing and maintaining effective communications.

Have a plan
High-performance teams do not rely solely on ad hoc communications; they have a formal communications plan. Here is an example of a communications plan recommended by Russian outsourcer, Luxoft:

I would add another row to this table that covers individual communications, which should happen on a daily basis. Individuals on the most successful teams I have seen make a point to at least check in at the beginning and end of their respective days. This is particularly important when working with vendors in India, and other areas where the work day tends to end as their client's day is getting started.

Many issues that arise during the course of a project can receive almost around-the-clock attention if both client and vendor make a point to check in at the beginning and end of each day. Conversely, failure to check in at the beginning and end of each day may result in a 1-day delay in addressing issues that could impact a project's critical path.

Engage at all levels
Engagement tends to follow the org-chart in both client and vendor organizations because that's the path of least resistance. Individual contributors for both clients and vendors tend to engage and communicate with their supervisors rather than their counterparts in the other organization. It's easier to walk over to another desk or hain the hallway than it is to reach out and touch someone on the other side of the planet whose day is winding down when you are just waking up.

In some cases, vital information that needs to cross organizational boundaries gets passed up one org chart several levels before it makes its way across to the other organization; and then the information has to get passed back down the other org chart before it gets to someone who can use it. This is typical bad engagement:

Many of us have simulated this kind of communications in management training classes, where we sit around a table in the same room and one person starts by passing a simple message to his or her neighbor. The message gets passed from neighbor to neighbor until it gets back to the person who originated the message. It's never the same as it started.

Now imagine conducting the same exercise with participants all over the world instead of in the same room and complex software requirements rather than simple messages. It can't possibly work!

If you have information to share, share it directly with everyone on the team who needs the information, regardless of where they are in an org chart.

Note: the engagement diagrams are from an internal presentation that was delivered to DoubleClick's internal and vendor teams by John Pavley, VP of Ad Management Engineering. Thanks, John!

Be constructive
It's easy to let yourself start treating your offshore team differently than you treat your onshore team. After all, they're vendors. But unlike some vendors that might come and go, your offshore relationship should be around for a long time. The value you can realize from working with your offshore vendor will come from a series of projects delivered over many years, more than from any one project.

Creating an environment where both client and vendor personnel can provide constructive feedback to one another is critical to establishing a long-term relationship. Here are some points to keep in mind:
  • Feedback should be fair, accurate, detailed, timely, and helpful
  • Find both formal and informal ways to give feedback
  • Remember to provide both positive and negative feedback
Building the right software is difficult, and it can be quite expensive. Working with offshore developers can make many projects financially possible, contributing both value and cost savings to businesses that can make global development work. These benefits can only be realized by companies that institutionalize effective communications by:
  • Using multiple communications channels
  • Having a communications plan
  • Engaging at all levels
  • Being constructive
See below for more information about the Web cast.

Getting Smart About Global Development: How Visual Simulation Gets It Right the First Time
Information Week TechWebCast sponsored by iRise.
March 23, 2005

Stephanie Moore, Vice President, Forrester Research
Mike Pithawalla, General Manager and Chief Architect Wipro
Martin Wischhusen, Director eBusiness Agilent Technologies
Mitch Bishop, Chief Marketing Officer, iRise

Note: You'll need either Windows Media Player or Real Player to view the panel discussion.