Requirements Communication in IT Offshoring - Case Study

Featured
17008 Views
4 Comments
3 Likes

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:

  1. Requirements Communication
  2. Knowledge sharing
  3. Language, and
  4. 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:

  1. Collaborating and bridging the differences;
  2. Acknowledging and managing the problems; and
  3. 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

Like this article:
  3 members liked this article
Featured
17008 Views
4 Comments
3 Likes

COMMENTS

Mark Monteleone posted on Thursday, December 24, 2015 4:21 PM
Thanks for writing this article. I appreciate your effort in sharing the results. The findings confirm some of the best practices I learned in agile training.

• Collocating the business and technical team
• High involvement of business people in daily technical team activities

Although the above practices help with the software development challenges, I don’t believe the challenges can be resolved. We just need to continue our heighten awareness and manage the work.
mmonteleone
Adam Alami posted on Saturday, December 26, 2015 2:21 PM
'I don’t believe the challenges can be resolved. We just need to continue our heighten awareness and manage the work ' I agree. The key word is awareness and managing the issues that rise from these challenges.
adamalami
Wilco Charité posted on Thursday, January 7, 2016 5:43 AM
Dear Adam, I can promise you something. When you already think differences cannot be resolved, they WILL certainly not be resolved.
Great article. In my opinion, the lack of clients domain knowledge is the biggest issue, the other three are solvable relatively easy compared to the domain knowledge. My own personal experience, offshoring or not, is that lack of knowledge of the context (for what kind of environment are we building something, what problem are we solving, what are the main expected benefits) do not help the development department. Knowledge about what I just mentioned, gives the developer, next to the requirements themselves, a reference for a kind of self check and a direction. "Why does the customer want this?" (how better the requirements, how less the questions). A very important activity for the Business analyst/Requirements engineer/Project manager during (off-shore) development is checking the understanding or "create common understanding" and guarding that the built product is what the client is expecting. The second biggest danger during development is that a developer has a question about a requirement. The biggest danger during development is that the developer will answer his own question himself. Check the understanding. Continuously!
wilco.charite
Adam Alami posted on Thursday, January 7, 2016 2:48 PM
Hi Wilco, agree. We tend to under estimate the value of the context in the requirements process.
adamalami
Only registered users may post comments.

 



Upcoming Live Webinars

 




Copyright 2006-2024 by Modern Analyst Media LLC