Role of “Bridge Person” in Software Development Projects

Conference paper
Part of the Communications in Computer and Information Science book series (CCIS, volume 756)

Abstract

Well-defined requirements articulating user expectations and needs are a key to successful implementation of software development project. However, business process experts often lack experience in requirement definition, are ill-equipped to interact directly with system developers and sometimes are even unable to agree upon common understanding of the expect end-product. To mitigate this issue, projects frequently involve a so called “bridge person” – a team member with an objective to facilitate smooth communication among technical and non-technical individuals. The objective of this paper is to evaluate “bridge person” importance and summarize aspects that impact selection of a right “bridge person” type in particular software development project. The paper summarizes information about the role of “bridge person” and presents the survey of industry’s perception of this role.

Keywords

“Bridge person” Software development project Business requirements Stakeholders Requirements analysis 

1 Introduction

Information system (IS) or software is developed in projects with an objective to satisfy customer requirements within planned time and resources. However, data by to one of the leading research organizations the Standish Group [1] show that it is difficult to complete software development (SD) projects successfully. Every year approximately 20% of the projects fail, about 50% of the projects are delayed, exceed budget or do not deliver all planned functionality, and only 30% of the projects are successful [1].

Another important factor is that since the 1990s one of the TOP 3 reasons of SD project failures has been related to the requirements analysis [1, 2, 3]. Project requirements analysis (PRA) stage problems are divided into three main categories: problems of scope, problems of volatility and problems of understanding [4]. However, all these problems have common reasons related to poor understanding of requirements, lack of communication and conflicting views of users on requirements [4]. These facts suggest that requirements are clearly articulating business needs and user expectations are a key to successful implementation of SD projects [5, 6]. Therefore, the PRA stage has a profound impact on the project success. This stage is one of the most challenging stages of projects because it involves identification of all stakeholders, understanding of their language, understanding, and management of their issues and expectations, as well as expression of the requirements in a form comprehensible to system developers [7].

As customer stakeholders often lack experience in requirement definition, they are ill-prepared to interact with system developers and sometimes are even unable to agree upon common understanding of what they would like to have built. “Bridge person” is involved in projects as a mediator among technical and non-technical individuals [8]. This person sufficiently understands business processes, is able to listen to stakeholders and at the same time has an understanding of the IS development area, thus being able to provide the necessary link between two parties in the development project [8]. However, each project has unique requirements and selecting right specialist is a challenging task, and there is a different type of “bridge person”. Therefore, some guidance for selecting the right “bridge person” is desirable.

The objective of this paper is to evaluate “bridge person” importance and summarize aspects that impact selection a right type of “bridge person” for a particular SD project. Also, the authors also draw attention to the importance of requirements analysis stage, the significance of “bridge person”, represent results of the survey on industry’s perception of this role in SD projects and propose solution how selection a right type of “bridge person” can be formalized.

The rest of the paper is structured as follows: Sect. 2 describes theoretical background and related studies; Sect. 3 presents the survey results; and the aspects for “bridge person” type selection and process formalization solution is presented in Sect. 4. Conclusion and future research are presented at the end of the paper.

2 Literature Review

This section summarizes theoretical background and related studies about the project requirements analysis stage, the role of “bridge person” and performers of this role in SD project and different SD models.

2.1 Requirements Analysis Stage

The project requirements analysis (PRA) stage is a first part of the software development process and plays an important role in quality assurance of developed system [9, 10]. The goal of PRA stage is to understand the users’ needs, collect and analyze them, and then document into correct, consistent, verifiable and feasible system requirements [10, 11]. Incoming and outgoing information and activities of this stage are shown in Fig. 1. This flow of information is similar for all organizations in all of the types of SD projects [7]. The activities of PRA stage are divided into two groups – requirement development and requirement management activities [11].
Fig. 1.

Overview of PRA stage

adopted from [7, 11]

Requirement development activities must answer to question “WHAT is needed to be created?”. Sequential execution of this group activities provides a road from incoming information to outgoing [10, 11]. The following activities are performed: (1) requirements elicitation that records and summarizes available information from all possible sources of information; (2) requirements analysis that discussed, detailed and prioritized the elicited requirements with the stakeholders; (3) requirements specification that produces requirement document which become a foundation for further software design and development process and (4) requirements validation that makes sure that all previous activities acquired and documented requirements are clear and feasible, and that all the requirements in the document are aligned with the organization standards and industry best practices.

Requirements management activities control accepted requirements, specifications, and models of consistency and constancy of the SD process [10, 11].

2.2 Role of “Bridge Person”

“Bridge person” is an individual who serves as the principal mediator or communication channel between customer stakeholders and system developers. His main task is to provide a link through which the customer stakeholders in non-technical language expresses requirements flow to system developers in a way understandable to them [8, 11, 12].

“Bridge person” is a project role but not necessarily a job title. This person can have different job title – business analyst, requirements analyst, systems analyst, product owner, requirements engineer, project manager, or any other specialist from customer, developer or independent organization, who perform responsibilities of this role. These job titles are used inconsistently from organization to organization. Regardless of the job title, the person performing a moderator role must have right skills, knowledge, and personality to perform this role well [11, 12].

“Bridge person” facilitates SD project incoming and outgoing information flows (Fig. 2), through incoming information transformation, structuring and transfer to system developers [11]. This person helps stakeholders to harmonize expressed and actual needs [11, 13].
Fig. 2.

“Bridge person” as communication channel,

adopted from [11]

According to [11, 13, 14], the main responsibilities of “bridge person” are: (1) define business needs; (2) plan the requirements approach; (3) elicit requirements; (4) analyze requirements; (5) facilitate prioritization; (6) write specifications (7) communicate requirements; (8) lead validation and (9) manage requirements.

Since “bridge person” is more than a person who only records requirements, this role includes many “soft skills” that are more people-oriented than technical [15]. “Bridge person” needs to know how to use many different methods (elicitation, analysis, modeling, etc.) and how to represent information in forms other than natural-language text. An effective “bridge person” combines strong communication, facilitation, and interpersonal skills with technical and business domain knowledge. Patience and a genuine desire to work with people are this role’s executor key success factors [11].

In practice, three types of “bridge person” can be identified. They mainly differ by their affiliation, primary responsibilities and core competencies [16]: (1) “bridge person” on customer side; (2) “bridge person” on developer side and (3) “bridge person” as an independent consultant. All three types are characterized in Table 1. While the main responsibilities and competencies are similar regardless of affiliation, there are some changes in emphasis.
Table 1.

“Bridge person” types and their characteristics

2.3 “Bridge Person” in Software Development Projects

Software development life cycle (SDLC) covers all software development activities from inception till software deployment and exploitation [17, 18]. To manage SDLC activities, a number of SDLC models have been created, such as traditional or predictive, iterative and incremental and adaptive life cycle model [19]. PRA activities and involvement of “bridge person” varies according to SDLC model used. In addition, depending on SDLC, PRA stage activities can be carried out at one or more times during the project (Fig. 3).
Fig. 3.

PRA stage activities on project timeline [11]

Traditional SDLC models (such as waterfall and V model) are based on a sequence of activities, where each subsequent execution needs previous results. PRA stage activities occur only once at the beginning of SD project. The requirements are only revisited in a testing phase to evaluate the system against the requirements. The largest workload of “bridge person” in these projects is in the first quarter of the total project timeline. In this type of projects, “bridge person” involvement is short but very intense. In addition, all requirements are collected at one point, and their reformulation is not intended. Thus, “bridge person” impact on project results is very high [11, 19, 20].

Iterative and incremental SD (often for simplicity referred to “iterative SD” [21]) is based on the idea of a progressive development process in which the whole system is divided into smaller parts – “steps” or “iterations”. At the beginning of the project, only common top-level system requirements are defined, and detailed requirements analysis is repeated at the beginning of each iteration. Duration of one iteration is up to three months. A PRA stage activities workload curve varies. Initially “bridge person” workload is slightly higher than during the next iterations, since of the project beginning in addition to the iterations requirements defines the common top-level system requirements. In general, it may be determined that the “bridge person” participation in these projects is continuous. The amount of work aggregated for all iterations could be almost equivalent to traditional SD projects, but less intensive at times leaving space for correcting errors [11, 21].

Adaptive SD (also known as agile SD) focus on lightweight processes, which allow for rapid changes and continuous involvement of stakeholders. In this methodology, detailed analysis and documentation are not performed in their standard meaning but are tightly coupled with other concurrent activities. When the project is starting, project’s top-level system requirements in a form of user story are summarized in the product backlog, and at the beginning of each iteration highest priority user stories are selected, detailed, developed, and tested together with stakeholders. The iterations are shorter than in iterative SD [11, 19, 20, 21, 22].

In agile projects, requirements are managed differently than in two earlier SDLC, and “bridge person” has a slightly different role [22]. Often “bridge person” are constantly supporting a product owner or performs this role [23]. The product owner is responsible for all user stories in the product backlog correctness, detailing and prioritization [23]. His participation is continuous, but its intensity strongly varies.

3 Survey

An industry survey is conducted to investigate the importance of the PRA stage and role of “bridge person”. Based on the theoretical analysis the following objectives are set for the survey:
  • to evaluation a level of recognition of the role of “bridge person”;

  • to identify a level of involvement of “bridge person” in SD projects;

  • to gather information on job titles including “bridge person” responsibilities;

  • to summarize most important competencies of “bridge person”.

The online survey was selected as a data collection method and sent to a number of organizations in Latvia, as well as it was placed in several social networks with different SD projects related groups. The survey was completely anonymous.

64 respondents participated in the survey and mostly with at least more than five years of experience in software development projects. Distribution of SD project parties and their sphere of activity are shown in Fig. 4. The respondents’ breakdown by the sphere of activity shows that the survey respondents have represented a wide number of sectors.
Fig. 4.

Respondents breakdown by involved party and organization sphere of activity

To evaluate recognition of the “bridge person” role, the respondents were asked to recognize this role without any additional explanation. That resulted in 33% of the respondents recognizing the role (Fig. 5). After the additional explanation, this role also recognizes by the remaining respondents.
Fig. 5.

Respondents’ assessment of “bridge person” recognition and contact on a daily basis

In addition, the majority of respondents (97%) says that they have been in contacts with this role performer on a daily basis in their own or other organization. Figure 6 shows job positions of this role at customer and developer side.
Fig. 6.

Respondents marked job positions

Based on the answers (Fig. 7), it can be concluded that the respondents are not only in contact with the “bridge person”, but “bridge person” is also actively involved in almost all organization’s projects. According to respondents rating, two most popular and frequently in projects involved “bridge person” types is the “bridge person” on the customer side and “bridge person” on developer side (Fig. 7) with a slight preference for having the “bridge person” on the customer side.
Fig. 7.

Respondents’ assessment of “bridge person” involvement in projects and it types

The most important “bridge person” competences following the respondent’s opinion are shown in Fig. 8. Communication skills, analytical thinking, and collaboration skills are evaluated as three most critical competencies.
Fig. 8.

Respondents’ assessment of “bridge person” competencies

4 Selection of “Bridge Person” Type

The aspects that impacts selection of an appropriate “bridge person” type for a given SD project we define as multi-criteria decision-making problem. Hierarchical decomposition of the aspects or criteria for selection of “bridge person” type is given in Fig. 9. The description of SD project situation is based on four groups of criteria including sub-criteria that are defined according to the theoretical analysis of “bridge person” role tasks and required competencies for the particular SD project based on the product that is developed and development process. These four criteria groups or clusters are: (1) criteria related to the customer – “C1: Customer” -; (2) criteria related to the developer – “C2: Developer”; (3) criteria related to the system – “C3: IS development product” and (4) criteria related to the development process – “C4: IS development project”. A large impact to selection of “bridge person” type are customers as it existing competencies and need for addition competencies mainly impact decision about “bridge person” type.
Fig. 9.

Description of “Bridge person” type selection problem

As one of solutions and examples how to solve this selection problem and test proposed selection aspects, a decision-making matrix [24] has been created by using Analytic Hierarchy Process (AHP) method [25] that allows to identify varying impact of evaluation aspects to decision-making.

Impact of each criteria clusters (c i , i = 1..4) is specified by the relative weights (\( w_{i}^{'} \)). According to the authors evaluation by taking into account the theoretical knowledge gained in Sect. 2 and the survey data in Sect. 2 the current values of weights are 0.51, 0.32, 0.10 and 0.07. Weight values approve previous assumption that the customer related criteria’s have the largest impact on results. Each sub-criterion (c ij , i = 1..4, j = 1.. k, k – count of sub-criteria in i cluster) also have their own AHP relative weights (\( w_{ij}^{''} \)). The summary sub-relative weights of criteria are calculated by multiplying two previously obtained weights (\( w_{ij} = \,w_{i}^{'} * w_{ij}^{''} \)).

For decision-making matrix creation, the mapping between the project situation and the “bridge person” type is established. For every criterion c ij , there are m potential answers characterizing the project situation. Their value is denoted by v ijs , s = 1.. m, where s is the answer. The most suitable type of “bridge person” is identified for every answer by assigning a rank using the eleven points rating scale (r ijst , t = 1..3, where t – “bridge person” type). These ranking is performed by the authors and these values are also possible to calibrate.

The weights and rankings constitute the setup of the proposed solution. Also, interactive interface based on Excel has been created that helps to guide through number of evaluation criteria and automate calculation of results. To apply the proposed solution for selecting the appropriate type of “bridge person” for the given project, the following steps are performed:
  1. 1.
    Fill a spreadsheet with values (v ijs ) for every criterion (c ij ) to describe the project situation (example is given in Fig. 10);
    Fig. 10.

    Example project criteria values

     
  2. 2.

    Read the rank values of answers for each “bridge person” type (r ijst );

     
  3. 3.
    Calculate a suitability rank for each “bridge person” type by using the following formula: \( R_{t} = \sum\nolimits_{ij} {w_{ij} \times r_{ijst} } \). As a result, the suitability rank each type of “bridge person” is shown (Fig. 11).
    Fig. 11.

    Example project results

     

In the example, the highest rank is for the “bridge person” on customer sides. In this case, that is strongly influenced by relatively high internal development competencies at the customer side and the long project duration. The projects situation described is drawn from observations in practice, and a posterior evaluation of this selection corresponds to what was used in the project.

5 Summary and Conclusion

During this research the requirements analysis stage has been analyzed as it has the profound impact on IS development. If requirements analysis is carried out properly, then it can be argued that the SD project will be successful and the system will satisfy customer needs. Even though there is a rich literature on requirements management, not a single method can resolve all the challenges, especially, those associated with the human factors.

The “bridge person” role is one of the solutions to deal with the human factors. Responsibilities of this role are to ensure the proper information flow between the representatives involved in the project. The authors draw a conclusion that involving “bridge person” in SD projects and the PRA stage in particular serves as an enabler of successful project completion.

Selection of the “bridge person” type is influenced by four important factors – customer, developer, system and SD project characteristics. The most significant of them is customer because only they know what is needed. That is why “bridge person” on customer side has significant advantages compared to the other two types.

Based on the analyzed literature and the results of this paper, potential future research directions are:
  • consideration of additional factors in the selection problem sphere, for example, costs and more detailed characteristics of systems by area of application and technology used;

  • distinguishing between different levels of qualification (e.g., beginner, intermediate and expert) of “bridge person”;

  • the combination of the “bridge person” role with related roles;

  • further evaluation of the solution for selection of the “bridge person” type.

References

  1. 1.
    Standish Group: Standish Group 2015 Chaos Report. https://www.infoq.com/articles/standish-chaos-2015
  2. 2.
    Attarzadeh, I., Siew, H.: Project management practices: success versus failure. In: Proceedings of the 2008 International Symposium on Information Technology (2008)Google Scholar
  3. 3.
    Stepanek, G.: Software Project Secrets: Why Software Projects Fail. Apress, New Zealand (2005)Google Scholar
  4. 4.
    Kumari, S., Pillai, A.: Requirements elicitation issues and project performance: a test of a contingency model. In: Proceedings of the 2015 Science and Information Conference (2015)Google Scholar
  5. 5.
    Liao, H.: Requirement elicitation of enterprise informationization from view of VCA. In: Proceeding of the 2010 International Conference on Networked Computing (2010)Google Scholar
  6. 6.
    Noraini, C., Abdullah, M.: Requirement elicitation: identifying the communication challenges between developer and customer. Int. J. New Comput. Architectures Their Appl., 371–383 (2011)Google Scholar
  7. 7.
    Arif, S., Khan, Q., Gahyyur, S.: Requirements engineering processes, tools/technologies, & methodologies. Int. J. Rev. Comput., 41–56 (2009–2010)Google Scholar
  8. 8.
    More, J., Stieber, A.J., Liu, C.: Breaking Into Information Security. Syngress, USA (2016)Google Scholar
  9. 9.
    Haron, A., Sahibuddin, S.: The strength and weakness of requirement engineering (RE) process. In: 2nd International Conference on Computer Technology and Development (2010)Google Scholar
  10. 10.
    Eleiche, A.M., Ahmad, I., Elish, M.O.: Design requirements in software and engineering systems. Ind. Eng. Manage. Syst., 70–81 (2012)Google Scholar
  11. 11.
    Wiegers, K., Beatty, J.: Software Requirements. Microsoft Press (2013)Google Scholar
  12. 12.
    Hickey, A., Davis, A.: A tale of two ontologies: the basis for systems analysis technique selection. In: 9th Americas Conference on Information Systems (2003)Google Scholar
  13. 13.
    International Institute of Business Analysis: A guide to the business analysis body of knowledge (BABOK). International Institute of Business Analysis (2015)Google Scholar
  14. 14.
    Young, R.R.: The Requirements Engineering Handbook. Artech House Print on Demand (2003)Google Scholar
  15. 15.
    Darvill, L.: The importance of personal skills for the expert business analyst. Analysts Anonymous 11 (2012)Google Scholar
  16. 16.
    Lazdāne, G.: Projekta vadība un Biznesa analīze – duets vai solo? http://www.slideshare.net/IIBA_Latvia_Chapter/ba-pv-21112013lnpva
  17. 17.
    IEEE Computer Society: Guide to the Software Engineering Body of Knowledge (SWEBOK). IEEE Computer Society Press (2014)Google Scholar
  18. 18.
    ISO/IEC 12207:2008 Systems and software engineering – Software life cycle processes (2008)Google Scholar
  19. 19.
    Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK). Project Management Institute, Inc. (2013)Google Scholar
  20. 20.
    Yu Beng, L., Wooi Khong, L., Wai Yip, T., Soo Fun, T.: Software development life cycle agile vs traditional approaches. In: 2012 International Conference on Information and Network Technology (2012)Google Scholar
  21. 21.
    Larman, C.: Agile and Iterative Development: A Manager’s Guide. Addison-Wesley Professional (2004)Google Scholar
  22. 22.
    Paetsch, F., Eberlein, A., Maurer, F.: Requirements engineering and agile software development. In: 12th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (2003)Google Scholar
  23. 23.
    Gregorio, D.D.: How the Business Analyst Supports and Encourages Collaboration on Agile Projects. IEEE (2012)Google Scholar
  24. 24.
    Technology evaluation centers: what is decision matrix? http://www.rfp-templates.com/What-is/Decision-Matrix
  25. 25.
    Triantaphyllou, E., Mann, S.H.: Using the analytic hierarchy process for decision making in engineering applications: some challenges. Int. J. Ind. Eng. Appl. Pract., 35–44 (1995)Google Scholar

Copyright information

© Springer International Publishing AG 2017

Authors and Affiliations

  1. 1.Information Technology InstituteRiga Technical UniversityRigaLatvia

Personalised recommendations