In his book, Agile Modeling, Scott Ambler has an interesting chart that compares the richness of communication between documentation options and modeling options. Documentation options are less effective than modeling options. In order of increasing effectiveness, they encompass paper, audio tape and video. In terms of increasing effectiveness of communication, modeling options include email conversations, phone conversations, video conversations, face to face meetings and — most effective of all — face to face meetings at whiteboards.
Buyers and providers of outsourced software development services concentrate so much on efficiency-related metrics such as project milestones, deliverables, programmer productivity (number of lines of code written or function points), that they miss the forest for the trees. Many an outsourced software development project has been unsuccessful despite meeting most of the efficiency metrics. That’s because participants forget the single most primary determinant of success in outsourcing: communication! Ineffective communication can derail a project much more than any other factor.
In my February 2007 column, “Metrics for Outsourced Software Development,” I outlined three main areas of attention, people, technology and process metrics. Process metrics may be broken down into effectiveness and efficiency metrics. This month, I elaborate on communication effectiveness metrics involved in a typical software development project that has been outsourced.
Communication effectiveness can be ensured if we pay close attention to what communication mechanisms work best for the buyer and the service provider. Onshore, nearshore and offshore software development may all have different combinations of communication mechanisms that are effective, because of language, culture and time zone differences.
Why does communication effectiveness have such a disproportionate effect on software development? Because communication involves people! In his technical report on the topic, Alistair Cockburn characterizes people in software development efforts this way:
- People are communicating beings, doing best face to face, in-person, with real-time question and answer.
- People have trouble acting consistently over time.
- People are highly variable, varying from day to day, place to place.
- People generally want to be good citizens, are good at looking around, taking initiative, and doing “whatever is needed” to get the project to work.
This may explain what can go wrong in communications in an outsourced software development effort. Because of distances and differences in time zones, face to face meetings with all users may not always be possible. You could have different people on the buyer side conveying what they understood from end users as requirements to the service provider. People involved in the project with the client and the service providers may all be having good days or bad days at work or in their personal lives. This may affect the development effort in many subtle ways, laying the foundations for the success or failure of the effort to a large extent.
Alistair Cockburn also explains why face to face meetings are the best:
Being physically close to the other person affects communication. Whether it’s three-dimensionality, timing, smell or small visual cues, physical proximity matters.
People communicate through gestures as well as words, often making a point by gesturing, raising an eyebrow or pointing while speaking.
Vocal Inflection and Timing
By speeding up, slowing down, pausing or changing tones, the speaker emphasizes the importance of a sentence or perhaps its surprise value.
Questions reveal the ambiguity in the speaker’s explanation or the way in which the explanation misses the listener’s background. The timing of the questions sets up a pattern of communication between the parties.
Because the aforementioned documentation options may not have many of these characteristics, such as physical proximity or non-verbal cues, they tend to be less effective than, say, a phone conversation. A phone conversation may not be as effective as a face to face meeting and so on. One or more of the above modalities may be missing in less effective communication mechanisms. That may explain why you have a hierarchy of communication mechanisms.
It may not always be possible to have face to face meetings all the time, especially in software development work done offshore. A mix of communication mechanisms and making sure that one or more of these are used regularly smoothes out the problems in a realistic setting. One such combination of mechanisms and their periodicity is the communication pyramid.
If we use the less effective communication mechanisms like IM/chat or email much more frequently and mix it with a systematic, regular set of face to face meetings at least once a quarter, you’re mixing communication mechanisms that make up for the deficiencies of others; overall, that may give you an optimal set of mechanisms.
Communication Effectiveness Metrics
Software development projects vary greatly: software applications vs. software product development, client/server applications vs. server-based applications with browser interfaces or business-oriented or consumer-oriented (like Web 2.0) software. Depending upon the nature of the application, one or more of the following criteria may be chosen for measuring communication effectiveness:
Usage of Multiple Mechanisms
Given the practical difficulties in having face to face meetings whenever the need arises, especially in offshore software development projects, are we making enough use of real-time mechanisms such as chat and phone conversations? Are we scheduling face to face meetings regularly and not only when crises occur?
Verification of Effectiveness
How are we sure that we’re communicating effectively? In agile methodologies, periodic releases can enable double checking on whether communication was effective when we look at the outputs in the form of periodic releases. This feedback loop makes sure that course corrections can be made before we have bigger problems. In non-agile environments, there should be minutes of meetings, video conferences or formal requirements, design and change requests that document what was communicated in the meetings. More importantly, the person doing the communicating should verify if the listener got it right.
Communication Effectiveness Audit
Periodic, quick focus groups could be conducted to review and make changes to the communication mix and periodicity used.
Ask people experienced in managing outsourced software development efforts about the major factor that made a project succeed or fail. Nine times out of 10 they’ll trace it back to communication effectiveness. Engineers, project managers and end users are more comfortable looking at Gantt charts, Microsoft Project and Excel files with numbers and dates for milestones and deliverables. They’re generally not comfortable with “touchy-feely” stuff: communication effectiveness. However as Tom DeMarco in his famous book, Peopleware, pointed out, software development is all about people. Often, communication single-handedly makes or breaks efforts. Ensuring effective communication mechanisms can ensure the success of outsourced software development, particularly the quality of delivery!
Nari Kannan’s “Metrics for Outsourced Software Development”
Buy Scott Ambler’s Agile Modeling: Effective Practices for Extreme Programming and the Unified Process
Alistair Cockburn’s report, “Characterizing people as non-linear, first-order components in software development”
Buy Tom DeMarco’s Peopleware: Productive Projects and Teams