Offshoring has become a recognizable IT procurement strategy. The United States, European Union and Australia offshore 40%, 30-33% and 30% of their IT services, respectively.
The success of an Offshoring mission depends largely upon how good the relationship between the vendor and client actually is. Just like in any business relationship, fertility of this association will not be judged only by results, but by the processes that lead to these results, as well.
Business Requirements are central to Software Development Offshoring relationship. Requirements are not hard objects that can be put across as formulas or equations. Irrespective of the artifacts used in requirements communication, requirements remain soft objects subject to various interpretations that may leave many voids for assumptions.
The purpose of this article is to investigate the challenges of requirements communication in Software Development projects.
The Scope of the Research
This research is based on six distinctive case studies (illustrated below). Voluntary participations were sought for semi-structured interviews directed to bring forth in-depth information about a particular question at hand. This is, inherently, a qualitative research strategy, as the questions and answers are not quantifiable. To ensure that the inputs from the interviewees were relevant, the following qualifying criteria were established before gathering information:
- The interviewee is a stakeholder of Offshore Software Development Agreement with a minimum experience of 2 years.
- The agreement in question is ongoing.
- The participant has a direct stake on software requirements management
Table I: Details of Case Study Participants
Analysis
Collected information needs to be interpreted and analysed to arrive at conclusions. Since, this study is of qualitative nature, gathered data and information is subjective in nature. Techniques employed for assessing such subjective information are:
- The Hermeneutic Approach (where textual or text-analogous information is certain to the assessment)
- Pattern Matching (where emphasis lies of matching data with prepositions).
Although various constraints were identified on the analysis of the gathered data, the research focused on Requirements Communication and Management. The findings insinuate that Offshored Software Development projects experience difficulties in managing requirements. The identified issues are:
- Requirements Communication
- Knowledge sharing
- Language, and
- Defects Communication
Requirements Communication
In the instances studied, software requirements were gathered and documented at the client’s country and shipped to the offshoring provider. Participants discussed that relaying on written requirements was an issue. Furthermore, they explained that the use of emails and video conferences for clarifications was not helpful. This issue appears to be mainly rooted in the communication and language divide.
Participants discussed that volatile and complex requirements need an agile and flexible style of communication. The distributed nature of the model seems to restrict requirements communication to a written mode. Participants agreed that verbal communication and physical contact help in understanding the requirements.
Lack of access to the client’s domain knowledge
Participants noted that accessibility to the client’s domain knowledge is essential in the process of software development. A participant stated that,
“Software teams have hard times to develop software when they are not familiar with the client’s business domain.”
He further explained that it’s especially “hard” when the development team lacks the expertise in developing software in that business domain. Other participants also corroborated that requirements communication isn’t adequate to understand the client’s domain. They suggested that they would prefer to have “ongoing” interactions with the client during the software development process. One Software Developer stated the following:
“It’s not about the artefacts used in documenting the requirements. Using Use Cases or Prototypes didn’t make a difference. These artefacts do not provide a context. We need to understand the client business!”
Language
Although most participants have offshored to countries where the client’s language is the second spoken language, participants from both sides of the model discussed the language issue. They described language as a communication “barrier”. This can aggravate the already existing requirements understanding issue.
Software Testing and Defects Communication
Testing is quality assurance of the final solution and remedying defects. Communication of defects was a persistent issue. One participant stated,
“Most the time, we don’t understand the defects reported to us”.
Another participant explained that,
“What we think is a requirements defect category, they think it is a code defect category and vice-versa.”
It seems that the offshored product inherits the unsolved issues developed during the development phase. Participants discussed that maintaining the software in a distributed model is challenging.
Conclusion
To consider the standard Requirements elicitation, documentation, and validation to be the Requirements Development Process in an Offshoring arrangement is a naïve assumption, just as shipping the requirements to a faraway country and expecting smooth sailing is simplistic. Various factors like cultural differences, communication gaps, language barriers and knowledge sharing come into play.
So, what part does a Business Analyst play in this scenario? As I always preach, the Business Analyst mission doesn’t end at validating the requirements and shipping them over the fence. In an Offshoring arrangement, the Business Analyst mission is to bridge the gap between stakeholders and the offshore team to ensure the understating of requirements.
How to do that is a million dollar question. There is no magic formula! Achieving a better relationship in this model necessitates the combination of three ingredients:
- Collaborating and bridging the differences;
- Acknowledging and managing the problems; and
- Essentially, understanding that both parties have to work in unison while conceding the differences.
Other issues like cultural clashes and communication gaps, however, will still exist. An ongoing monitoring and medication of floating issues can be the way forward to tackle this dilemma. Requirements communication in an Offshoring arrangement has many added dimensions. Traditionally, a Business Analyst could allow for knowledge sharing between technical team with timely collocation and in-person meetings. Geographical distance, inability to carry out candid conversations, passive communication methods and cultural gap all contribute to inefficient communication of Requirements – a hurdle that every Business Analyst is required to deal with ingenuity, ongoing knowledge sharing, foundation of mutual trust and patience.
Author: Adam Alami, Sr. Business Analyst
Adam Alami is a seasoned IT consultant with over 18 years’ experience. Business Analysis and Project Management is his passion. His experience revolved around major business transformation projects. He is a versatile IT professional. He accumulated a wealth of cross industry experience with Tier 1 businesses in major projects in the areas of Enterprise Transformation, Integration, Migration, and Systems Modernization.
Adam has a passion for research. His research interests are IT Offshoring, Global Project Managements, Banking Technology, Business Analysis, Information Technology and Culture, Enterprise Innovation and Business Solutions.
Email: [email protected]
Website: www.adamalami.com