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.

Sunday, March 27, 2005

A Turn-around Story

Once our onshore teams are beyond FUD, our next challenge is making sure that the success of the onshore and offshore teams are one and the same thing.

I had one situation where a first-time manager was managing a 5-person offshore team. This manager wasn't really ready for the job; it was kind of thrown upon him without discussion or training. It wasn't so much that he was affraid his job would be sent offshore but that he didn't really understand what was expected of him so he couldn't help his offshore team be successful. He was dictatorial, he gave his team the busy-work that he didn't want to do himself, and his offshore team resented his behavior. Their performance was poor; and they were all ready to quit!

Before replacing the manager, we gave him a chance to improve: we set clear goals for him, provided plenty of coaching, and re-engaged his team on a visit to India.

Now, they are a model of effective offshore development at DoubleClick and he is probably our most improved manager. He invests tremendous time and energy in making his offshore team successful by focusing on communications, motivation, knowledge transfer, and team building. His team's performance is outstanding!

A side note: this particular team does visual design work for us, which requires tremendous collaboration with development teams both in N. America and India. It's a very challenging domain to send offshore, to begin with!

Sunday, March 20, 2005

Overcoming Fear, Uncertainty, and Doubt in Offshore Outsourcing

Offshore outsourcing can easily backfire if team members succumb to Fear, Uncertainty, and Doubt (FUD). Interests of internal and external team members start to diverge, and everyone becomes less effective. The key to overcoming FUD is to bridge the gap between "us" and "them" so that internal and external team members are interdependent on one another for shared success.

At DoubleClick, we build virtual project teams that include full-time employees and consultants from our offshore vendor. The bottom line for us: on a day-to-day basis, teams that are successful think of one another as peers working for the same company. The only differences should be physical location and who writes the paychecks. Teams that aren't as successful tend to think of the offshore team members as a souce of cheap, overflow labor to take on everything that the folks in N. America don't want to be bothered with.

Our model doesn't work at all if our full-time employees are affraid that their jobs will be sent offshore. When guided by FUD, they can't have an interest in their offshore team members' success. One point we continually remind our onshore team about is that we are growing both teams, not just the offshore team. We're not laying off onshore personnel or reducing onshore headcount through voluntary attrition. No matter what we say, though, our actions have to do the hard work of convincing skeptics that their jobs are not in jeopardy.

FUD is not limited to full-time employees, either. Offshore team members can also be uncertain about their future if their client isn't fully engaging them in the project. For example, if the offshore team does not have access to enough, timely information about the business and the project requirements, they will be uncertain about their project's chances for success, upon which their future promotions will depend. They may tend to follow stated requirements to the letter than ask questions to clarify requirements. In the best-case scenario, requirements will need to be clarified and the project will be late. In the worst-case scenario, requirements will not be clarified and the deliverable will not deliver the expected value.

Narrowing the gap between client and vendor helps address both onshore and offshore team members' FUD. At DoubleClick, we started by building an atmosphere of mutual trust and respect. Some teams had a long history of working together and this atmosphere was already present. Others were just getting started and had to be actively coached to see their common goals and interdependence before they were open to mutual trust and respect.

Overcoming FUD, however, is only one step towards effective offshore outsourcing; doing so helps prevent team members from being de-motivated, but it does not necessarily drive team members to maximize performance. This is really "Motivation 101."

For a refresher on motivation, look at Maslow's Hierarchy of Needs and Herzberg's Dual Factor theory. In short, Mazlow and Herzberg's theories state that meeting the more basic human needs of physiology, safety, and belongingness is necessary to prevent people from being de-motivated, but not sufficient to motivate people to maximize performance. To drive performance, we must go a step further and address higher-level human needs like self-esteem and self-actualization for both onshore and offshore team members...

But this is a topic for another day.

Wednesday, March 09, 2005


I decided to start a blog to encourage an open dialog about issues related to global software development.

For years, large companies have operated software development centers around the world; and many have realized significant returns, as a result. Now, much smaller companies, even emerging companies and startups, are turning to the global development community in search of benefits like lower development costs, increased velocity, improved agility, and access to specialized skills.

These trends are fueling growth in the IT services industry around the World. For instance, The Meta Group predicts a 20% CAGR in the Indian IT services market through 2008. Eastern Europe and China are also rapidly emerging as powerhouses in this segment.

The bottom line is that there is literally a World of options for sourcing development, allowing companies to optimize development and maximize business results. The days of co-located development teams are numbered. It behooves technology professionals at all levels to learn how to be effective in global software development environments.

Please share your thoughts and experiences. In no way do I suggest that I have all of the answers. I will probably make some controversial statements; whether you agree or disagree, I hope you feel comfortable adding your opinion.

I plan to start by capturing my thoughts and observations on offshore outsourcing. My experience with offshore outsourcing started last year, when I joined Doubleclick as VP of Engineering. I am also active in the Society for Information Management NY Metro chapter outsourcing special interest group and the Technology Executives Networking Group, both of which provide much fodder for discussion.