New communication technologies always bring along new chances and ways of conducting daily business operations. In this context, the utilisation of the internet to collaborate with trading partners depicts a notable advance within the last two decades. These direct electronical collaborations are commonly labelled as business-to-business (B2B) applications, which for example target “e-procurement, supply-chain management (SCM), and B2B e-payment” (Al-Naeem et al., 2005, p. 41). Due to the rise of mobile devices like smartphones or tablets and the concomitant increased usage of professionals’ mobile devices during work, especially mobile B2B applications have been evolving as an important tool for customer relationship management (Smilansky, 2015). Nowadays, people already spend more time using mobile applications than internet via traditional desktop computers (Zamfiroiu, 2015). Well-known software manufacturers already detected this development, offering mobile B2B applications for multiple business purposes (Tornack et al., 2011).

The client, an SME providing food products to catering companies, is aware of this progress and intends to program and implement a mobile B2B application for his customers. However, due to the high complexity of such IT projects, only an extensive exposure of the requirements can prevent the project from certain failure (Azadegan et al., 2013). Based on the results of more than hundred research and development projects, Dvir et al. (2003) point out that project success is strongly correlated with the definition of those requirements. In order to determine relevant requirements of this project, a study shall provide valuable information about different project necessities. Regarding software development, this process is commonly labelled as ‘requirements engineering’ respectively ‘requirements elicitation’ which describes “seeking, uncovering, acquiring and elaborating requirements for computer based systems” (Zowghi and Coulin, 2005, p. 19). Although requirements elicitation is mostly perceived as the first major step of a software engineering project, the shape of its process and used methods varies, depending on the particular project (Vijayan and Raju, 2011). Hence, this report can be understood as a consulting offer to conduct a requirements elicitation study, outlining all pertinent methods which are of importance for the individual case of the client.

It is of fundamental importance that the study as well as the development of the mobile B2B application for the client itself can be seen as projects. Projects are unique sets of temporary activities with a definable goal, which cut across functional lines and imply risks as well as costs for an organisation (Nicholas and Steyn, 2012). That is why project management methods as well as experiences from software project management case studies will take a key role in the presented requirements elicitation approach. The study covers the following objectives and related methods in order to reveal the client’s requirements for the project of developing and implementing a mobile B2B application, whereas objectives and methods build on one another:

Objective 1: Identifying the functional requirements of mobile B2B applications within the food market for catering companies

· Stakeholder Analysis

· Software Benchmarking

Objective 2: Identifying the structural requirements to program and implement the application within the current company structure and capabilities

· System Environment Analysis

· Personnel Analysis

· Risk Identification and Analysis

Objective 3: Identifying the resources requirements the client has to raise for programming, implementing and operating the mobile B2B application

· Project Time Planning

· Life-Cycle Cost Analysis

At first, the offer will illustrate the intended relevant methods which are required in order to reveal the particular requirements of the three objectives. Here, the methods are described shortly, while evidences from project management background exemplify the adequacy of the methods. Based on the introduced methods and their approximate time need, the offer will illustrate the intended approach with the aid of a Gantt chart, providing an overview with start and end times for the individual project steps and methods. Subsequently, the contribution of the particular methods and the project as a whole will elucidate why the illustrated approach is the most useful one for the company’s objectives, supported by several industry cases. Finally, the concluding remarks will summarise the main details of the offer in order to provide final decision guidance towards this offer.

The general aim of the study is to provide a holistic research approach for the client, which covers all relevant kinds of requirements in order to assess the necessities of programming and implementing the mobile B2B application. The following chapter illustrates the background as well as the individual processes of the particular methods.

It has to be considered that the information gathering process of all the intended methods requires an open communicative exchange with the client. Changing client requirements or circumstances can occur during the whole requirements elicitation process and should be incorporated as soon as the changes are identified. Therefore, a continuous two-way communication process with the client in the form of a permanent contact person secures adequacy of the study (Nakatani et al., 2014). This is supported by Houdek and Pohl (2000) who examine the requirements elicitation process of Daimler-Chrysler projects and emphasise that over 50% of the requirements changes happen after the actual identification process.

As already indicated, B2B applications are able to cover several functionalities, from being just a marketing tool to comprising a whole e-procurement system including embedded sales and payment possibilities (Al-Naeem et al., 2005). In order to provide a basis for the further requirements analyses, the examination of the functional requirements focuses on the questions, how the application has to look like to please the stakeholders and in which functional direction (e.g. sales, marketing, supply-chain management, e-payment, etc.) the application has to go. Overall, the client receives knowledge about what the market and its key players require of the B2B application.

Stakeholder analysis as a project management technique is widely acknowledged among management practitioners and researchers as a part of the requirements elicitation process, providing a broad layer of necessary information (Glinz and Wieringa, 2007; Newcombe, 2003). Stakeholders of software are persons, organisations or other groups who affect or are affected by the software (Power, 2010). The technique tackles the questions of who the relevant project stakeholders are, how their wants and needs look like as well as how important they are in comparison to other stakeholders. It should be considered that each project has its own stakeholders which may partly not be that obvious as it would appear (Lock, 2013). All of these stakeholders have expectations for the intended software, with the wants and the needs often being in conflict with each other (Newcombe, 2003).

The stakeholder identification process for the client happens on the basis of a brainstorming meeting, as suggested by Calvert (1995). Here, also the client participates due to his superior knowledge of the internal proceedings and affected groups (Pouloudi and Whitley, 1997). The identification particularly focuses on what Sharp et al. (1999, p. 389) call ‘Baseline Stakeholders’, which represent internal and external “users, developers, legislators and decision-makers” with respect to the complete predicted software lifecycle. After the identification of the relevant stakeholders, direct stakeholder communication is necessary in order to determine their needs and requirements. This can happen through structured meetings or personal conversations. This step ensures an understanding and involvement of the relevant stakeholders from the beginning of the project (Passenheim, 2009). Also, the prioritisation of stakeholders and their individual requirements are elementary steps towards stakeholder comprehension since stakeholders are not equally important for the mobile application. Overall, this prioritisation has to consider the strategic adjustment of the company (Glinz and Wieringa, 2007). On the basis of these results, a final stakeholder matrix with objectives, priorities and contributions is produced (Lock, 2013). Difficulties during the stakeholder analysis may especially emerge in the case of hard accessibility of stakeholders as well as if there is an individual stakeholder with diverging inner objectives (e.g. in the case of a heterogeneous organisation) (Jepsen and Eskerod, 2009).

On the basis of the stakeholder analysis, the subsequent software benchmarking examines if there are already existing best practice examples in the market which coincide with the results of the stakeholder analysis’ objectives. Here, the analysis especially focuses on those functional requirements, which were identified by those stakeholders with the highest prioritisation. Benchmarking describes the practice of comparing the own organisational operations with equivalent processes of industries’ market leaders. Doing so, it is possible to gather information and achieve an improvement of the own business operations by applying this information (Watson, 1993). In this sense, software benchmarking can be understood as a certain kind of focused competitive analysis which, however, also includes software companies as well as best practice examples of comparable markets. With this form of an external benchmarking analysis, it is possible to set the functional requirements of the client on a level which enables him to compete with his competitors on a qualitative and technological high level (Hines, 1998).

After the prior techniques exposed the functional requirements of the B2B application, the subsequent methods will focus on the question, if the client fulfils the structural requirements to program and implement an application with such functions within the current organisational environment. Especially IT, personnel as well as risk capacities play a pivotal role due to their influence on the matter whether the client is able to solve respectively control deviations and occurring risks or whether external service providers could be an alternative.

The system environment analysis provides the basis for the structural requirements analysis. Before, the stakeholder matrix with its objectives and prioritisation as well as the results of the software benchmarking analysis revealed the functional requirements of the mobile B2B application (Nicholas and Steyn, 2012). Subsequently, the system environment analysis has to examine how “easy” it is to program and implement those functions within the client’s IT system environment. This process is highly relevant for the requirements elicitation process due to the necessity to embed the B2B application within the existing system environment (MacLean et al., 2004). An IT infrastructure consists of interacting subsystems which are part of the operative business (Singer et al., 2009). Embedding changes within such an IT environment which involves other entities creates constraints which are relevant due to the question whether the client is able handle these constraints (MacLean et al., 2004).

Hence, the analysis has to comprise the identification of existing systems, modules and interfaces (before) and of necessary systems, modules and interfaces (after) between the new mobile application and the existing system environment (Pries and Quigley, 2008). Furthermore, it has to reveal existing IT service, security and support processes which also have to be considered during the implementation of the B2B application. The foundation of the system environment analysis is an interview with the responsible IT leader or respectively the responsible application owner of the client, in order to get an overview of the related systems. For the case that the IT processes are administered by an external provider, it might be necessary to consult the provider as an additional information source. Also already existing system manuals can be drawn upon to collect information (Vijayan and Raju, 2011). On basis of the information gathering process, a before & after graphic of the IT environment is prepared. These graphics enable an understanding of which modules are affected by the new application and which additional interfaces respectively interface tools might be necessary to allow an automated data exchange and, hence, an operative usage of the application (Pries and Quigley, 2008). Analysing further needs which may be derived from the graphics will reveal possible necessary module adoptions. Depending on which systems are affected, it is also possible to detect which particular IT skills are needed in order to conduct these changes. This provides the basis for the subsequent personnel analysis.

After coming to know which functions need to be programmed, implemented and embedded, and how those functions have to interact with the system environment, it is possible to investigate which personnel resources are necessary to implement it. In order to determine the client’s requirements, an important point is the question if the client is able to provide the necessary personnel resources. Only if the client can provide the required employees and their related skill sets which are needed for the development and implementation of a mobile B2B application, a self-initiated project is executable (Project Management Institute, 2013). Moreover, the personnel analysis has to illustrate, how the project organisation is embedded within the organisation and how the project team itself has to be structured (Passenheim, 2009).

Training time of developers and other staff in order to acquire necessary skills can be quite intricate, so a systematic personnel analysis which compares necessary tasks and roles with the human capital of the client reveals the exact personnel requirements for the project (Otero et al., 2009). In this sense, the personnel analysis depicts an actual state analysis, comparing ‘what we need’ with ‘what we have’. In this analysis, the project role planning depicts the first step. Taking the data of the functional requirements and the system environment analysis as a basis, necessary roles have to be defined and adjusted to the client’s project. The project roles also have to consider and be embedded within the organisational hierarchy, reflecting administrative as well as technical tasks (Jucan, 2013). The second major step is the actual state analysis which takes the information gathered by the project role planning, comparing it with the organisational capabilities. Here, sources are the organigram of the client, position descriptions as well as a possible personnel data base. If required, an interview with the CEO or HR principle could deliver further insights (Project Management Institute, 2013). Problems could occur if the staff and skill set of the company is given, but the staffing collides with other operational responsibilities of the client. Furthermore, it can be hard to assess the amount of required roles for a new project with a new combination of project teams (Barreto et al., 2008).

The last step of the structural requirements analysis is risk identification and analysis. Although project risk management approaches normally contain the steps risk identification, analysis, planning and control (Nicholas and Steyn, 2012), the objective of assessing the structural requirements of the client to realise the project just requires the execution of the first two points. There is a broad consensus that a conscientiously conducted risk management approach is one of the major steps in the preparation of each project (Passenheim, 2009). Each project contains risks which can be defined as unplanned deviations from initial objectives. Although absolute elimination of risks is not possible, the common aim is to identify and control them (Nicholas and Steyn, 2012). Project risks can be caused by multiple elements and can occur at each project stage (Lock, 2013). Furthermore, they can be either based on internal or on external factors (Maley, 2012).

The basis of the risk identification is a brainstorming meeting, which is supported by a checklist of possible project risks, as suggested by Maley (2012). The checklist is provided by Boehm (1991). Furthermore, experiences from prior client projects have an impact on the identification process (Lock, 2013). This process contains each risk that may somehow have negative consequences for the project outcome. Once identified, the risks have to be analysed in order to allow for conclusions if the client is able to handle them. The factors risk likelihood and risk impact play a pivotal role in assessing the project risks (Nicholas and Steyn, 2012). Here, the analysis provides an ordinal scale (high, medium, low) for the likelihood as well as a quantitative cost estimation for the risk impact (Maley, 2012; Passenheim, 2009). Based on this assessment, the risks can be ranked in a matrix. Due to the fact that the risk identification and analysis affect multiple requirements elicitation areas such as IT, personnel, time and costs risks, the risk identification and analysis are conducted as an overarching process (see Gantt chart). This approach enables a gapless identification, considering the possibility that other methods also reveal additional risks.

After revealing the structural requirements for implementing a mobile B2B application, it is possible to conduct classical project management planning techniques in order to determine the required resources the client has to raise. The necessary resources probably constitute the most tangible kind of requirements, also because they are expressible in quantitative numbers. Overall, this analysis unveils, how long the software engineering and implementation process (including all necessary testing and coordination procedures) will take and which monetary resources will be necessary to conduct the project and handle follow-up costs.

Just like each project, the client’s mobile B2B software programming project consists of individual steps which have to be undertaken. In order to get an overview of the time the company has to spend for the project, project time planning is an important step to reveal temporal requirements. Especially for software engineering projects, time estimates depict a special challenge due to the high complexity and dependency on uncertain proceedings (Lock, 2013).

The two focus points of project time planning are the manufacturing of an activity-based network and on this basis, the drawing of a Gantt chart (Maley, 2012). The first step towards the network is to break down the project into activities in order to provide a foundation for estimation and scheduling activities. This step requires deeper knowledge in software programming and testing procedures, so that experiences from managers who were involved in software engineering projects as well as software engineering case studies support this step. Those sources, together with published estimation data, subsequently contribute to identify the approximate required time (Project Management Institute, 2013). Afterwards, the revealed activities have to be put into a logical sequence. Dependencies and individual task durations allow for drawing a network diagram, considering start times, end times and milestones (Passenheim, 2009). More detailed planning approaches would also consider costs and resource constraints for the individual steps, which for the scope of this study however is not relevant (Nicholas and Steyn, 2012). In the end, the network diagram results in a detailed Gantt chart, as introduced in chapter 3. Overall, the usage of project management software like MS Project is elementary for a project of such complexity and helps to avoid mistakes and secures reliability for the planning approach. Furthermore, it provides multiple options for the client regarding layout and reports of the time planning (Zhang and Bishop, 2013).

The second part of the resources requirements depicts the life-cycle cost (LCC) analysis. This technique tackles the questions of how much the cumulative costs for the client will be. Software products have differing life cycle phases with connected costs. However, many occurring costs are not obvious without an appropriate analysis (Eckardt et al., 2014). To determine the financial requirements of the mobile B2B application, LCC analysis appears to be a sensible approach for the client since it not only contains relevant programming and implementation costs, but also follow-up costs such as necessary operating, maintenance, support and disposal costs, from the beginning to the end of the product (Nicholas and Steyn, 2012). This technique is also necessary since those costs are interrelated with each other: Cost savings in the development and testing phase could lead to increased maintenance costs in the operating phase (Passenheim, 2009).

LCC can already be defined in the pre-project planning phase, providing an early overview over a long time range (Lindholm and Suomala, 2005). The LCC analysis considers five different types of costs: direct, indirect, contingent, intangible as well as external costs (Norris, 2001). This can for example be material, labour or overhead costs (Passenheim, 2009). The data collection process for the LCC happens with help of a bottom-up approach, applying activity-based costing which subsequently are accumulated (Vlachý, 2014). The software life cycle is separated into various phases in order to distinguish the functional stages (Kapp and Girmscheid, 2005). The results of the project time planning and its identified tasks provide a first insight over necessary project steps. The process is supported by an open-source estimation software and the calculations are based on market-based prices for hourly wages and necessary software tools (Abran, 2015). Finally, the individual costs are accumulated, providing a statement about the costs for the whole product life-cycle. However, the danger of LCC is a possible unreliability of data. Costs can vary over time, so that the analysis cannot anticipate possible changes (Higham et al., 2015). Hence, the result has to be seen more as orientation and not as hard fact. In the case of a final project implementation, the cost estimation will become on the basis of performance experiences more detailed and exact, improving its reliability (Passenheim, 2009).

As introduced, all techniques are connected by individual implementation steps and exhibit certain process durations. In order to provide an overview of the process of the consulting project for client, consultant and stakeholders, a Gantt chart is broadly identified as a useful tool (Locke, 2013; Nicholas and Steyn, 2012). The Gantt chart considers individual implementation durations of the single project steps as well as their dependencies. The dependencies are shown as “Finish-to-start” dependencies, which means that they illustrate which steps have to be completed before the dependent and following step can begin. On the other hand, the critical path exemplifies the order of those critical steps, which have to be completed to finish the whole project (Maley, 2012).

The entire study is scheduled for 6 months, which depicts 26 weeks, with a kick off meeting initiating the project. As already indicated, a continuous consultant-client communication ensures the adequacy of the study. However, this consistent possibility for consultation does not affect the meetings which are provided for the individual techniques. The kick-off meeting at the beginning of the study introduces the involved and responsible persons and presents relevant details regarding the particular project steps, as suggested by Passenheim (2009). While the first 22 weeks are part of the data gathering process, all information and notes will be shaped in week 23 till 25 in order to produce the study. Since risk identification and analysis are overlapping activities which include multiple factors, further adoptions may be made during the resource requirements analysis. In the last week, the client will receive the final report, including a presentation with recommendations towards further actions. Furthermore, an evaluation meeting will offer the possibility for both sides to provide improvement feedback for following consulting projects.

Figure 1 illustrates the Gantt chart, the sequence of the particular methods, their durations and dependencies. The task ID helps to orientate and to distribute the dependencies. While the task itself is conducted if the cells are filled, dashed cells symbolise that the individual tasks are ancillary processes at those points. Grey cells represent slack time, which enables the individual process to take longer, without increasing the critical path and the maximum duration of the project. However, due to the fact that the most processes build on one another, the Gantt chart does not provide much space for slack time. However, the project times were estimated permissively, so that there should not be any major delays:

After receiving an overview of the techniques and procedure of the study, the following chapter will in detail deal with the question of how the individual techniques contribute to the identified objectives and the overall aim of exposing all requirements for programming and implementing a mobile B2B application. Evidences from industry and software case studies are combined with insights researchers gained while using or investigating the particular techniques.

Overall, the client will obtain all necessary information which helps him to determine a picture of the project’s requirements from this approach. Furthermore, the client receives a holistic and scientific approach, providing detailed insights about potentials and possibilities for future IT projects within the company. Consequently, the client will be able to make further relevant decisions regarding the project. If the revealed functional, structural and resources requirements do not fit to the capabilities of the client, outsourcing the project could be a possibility. However, if the study shows that undertaking the project is within the capabilities of the client, the study already provides the first step of the project planning and requirements elicitation phase, saving time and money for the client.

Regarding the stakeholder analysis, Pacheco and Garcia (2012) point out that identification and understanding of stakeholders is critical for the requirements elicitation process and for the subsequent quality of the software. Only through the identification of all relevant stakeholders, software can fulfil sufficiently its value-based requirements (Babar et al., 2015). Applying a stakeholder analysis approach at a company which introduced an e-procurement system, Pan (2005) points out that understanding stakeholders and their objectives is crucial in order to avoid abandonment of information systems development projects. According to Kaur and Sengupta (2011), IT projects with a lack of user involvement can lead to a lack of commitment and a declining project support which is necessary for a successful project.

According to Vrhovec et al. (2015), stakeholder analysis before undertaking software projects is also strongly connected to the risk identification and analysis process due to the concomitant problems in the case of ignoring stakeholder needs. Based on a case study of an application development in the banking sector, they point out that especially the IT personnel’s understanding of the appropriate business process and the clear communication among stakeholders are of particular importance. Also Rost and Glass (2009) emphasise the impact of stakeholders on project risks, emphasising the need to analyse and assess them. Due to the coverage of all relevant market participants such as users, programmers and customers, a conscientious conducted stakeholder analysis in interaction with software benchmarking makes a market analysis redundant.

The fact that several software manufacturers already offer mobile B2B applications for several industries and business segments, illustrates that a software benchmarking analysis strongly contributes to the objective of revealing which functionalities are required and appropriate for a certain industry (Tornack et al., 2011). Overall, examining and adapting software best practices can help companies to succeed in high competitive markets such as the B2B food market (Ojala and Tyrväinen, 2008).

Investigating its application in France, Maire et al. (2005) find that 50% of the examined companies use benchmarking regularly in order to find best practices with the aim of improving IT processes. Applying benchmarking theoretically and practically on the requirements elicitation process of a website development project, Pang et al. (2009) illustrate that benchmarking is a useful tool in order to assess IT-based requirements. In the context of project management, Loo (2003) successfully applies benchmarking for technical aspects, proving the suitability of benchmarking for complex projects. Especially regarding the objective of revealing the functional requirements of the client’s mobile B2B application, benchmarking is able to provide valuable industry insights of already existing and adopted software. This fills the gap between those functional requirements already detected in the stakeholder analysis, and the functional requirements which are necessary for a practical implementation.

Regarding the application of the system environment analysis it has to be considered that this is not a classic technique used in software project management. However, considering the particular case of the client, the system environment analysis allows for conclusions about the subsequent personnel and risk analysis since a different IT environment requires a different need for staff and skill sets of the personnel and leads to different risks. Furthermore, practical implementations within several industry cases show its suitability regarding exposing structural IT requirements.

Charette (2005) summarises multiple failed software projects of small and large companies, with the result that IT problems as well as inadequate adaptions were responsible for a large part. Those problems can lead to foregone profits which can also be prevented by a focused analysis of the IT infrastructure of the client. Moreover, the system environment analysis allows further conclusions regarding the requirements of the IT security, service management and risk management which is supported by the case of a Greek software company undertaking implementation projects at clients (Maroukian, 2010). Also Byrd and Turner (2000) emphasise the IT infrastructure’s key role for the users (personnel) on the one hand and for further developments on the other hand in a broad-based study. This coincides with the introduced approach, which provides the system environment analysis to be a foundation of the subsequent personnel analysis.

The personnel analysis is highly recommended since developing, implementing and maintaining software is a people intensive task, not only regarding developers, but also for project managers, testers, administrative or maintenance staff (Barreto et al., 2008). Hence, only a focused analysis can illustrate the personnel requirements, the client will have to face. Also Firesmith (2004) emphasises that a case-based requirements elicitation approach always has to consider the scope and, hence, the required staffing. This especially concerns the client, who exhibits as an SME much tighter personnel resources as for example a multinational company.

Furthermore, Park et al. (2015) emphasise that planning and allocation of human resources and especially of developers during software projects to certain tasks and responsibilities depicts a necessity in order to handle time issues and to estimate the workload per employee. Hence, possible bottlenecks can be revealed before they occur. For the client, the personnel analysis depicts an elementary step in order to decide whether outsourcing the project or hiring external freelancers may be a sensible possibility. In the case of minor expertise gaps respectively shortages, freelancers could fill these gaps (Wu and Zmud, 2010).

Especially for the client, who intends to enter an unknown area with a new product, risk identification and analysis appears particularly important due to the high risk susceptibility of IT projects (Lock, 2013). The risk identification and analysis is crucial in order to classify the elaborated requirements and to assess if the client is able to handle the risks alone. This is supported by multiple cases: Applying a holistic risk management framework for a software engineering project in the Barbados government sector, Dey et al. (2007) point out that risk identification and analysis at the beginning of a software project depicts a necessity for ensuring a clear risk understanding and comprehension of which actions may be required to control those risks. According to Baccarini et al. (2004), who undertook interviews with leading IT experts, IT projects provide a large range of possible risks, especially regarding personnel, scheduling and budget. The introduced methodology considers this fact with respect to the implementation of an overlapping risk approach. Moreover, several examples of failed IT projects can be associated with missing or insufficient risk management, such as in the cases of “American Airlines AMR Information Services (AMRIS)” or the “London Stock Exchange’s Transfer and Automated Registration of Uncertified Stock (TAURUS) system” (Baccarini et al., 2004, p. 286). Hence, it is of particular importance for the client to receive an overview of the risks and required countermeasures in order to assess the capabilities the firm has to raise to handle the risks.

In order to assess the resources requirements, project time planning plays a crucial role for companies due to multiple problems which occur with time: Bottlenecks and inaccurate time estimates can cause time pressure and even late delivery, which also negatively affects the project costs (Hazzan and Dubinsky, 2007). Providing several examples of failed IT projects, Charette (2005) illustrates the necessity of an appropriate project time planning technique for the appropriate estimation of temporal requirements. Although IT project estimation often is not an exact science, scheduling is a step towards less uncertainty.

Examining the adoption of time planning approaches for software projects, Verner et al. (2007) find out that unreasonable time planning goes along with inadequate requirements engineering, leading to rising time risks, while the failure of many projects can be derived by those events. Hence, a conscious analysis with reasonable time estimation can prevent the client from wrong time assessment, occurring risks and connected losses.

Regarding the project requirements, costs often are a major reason for or against implementation (Passenheim, 2009). Applying LCC in an engineering project, Vlachý (2014) proves that LCC is a very comprehensive and detailed technique regarding assessing a company’s product costs till the end of the product life cycle, especially when the technique is already applied in the product conception phase. The assistance of LCC for the strategic decision-making depicts a major advantage of the technique (ibid.). This coincides with the advantages of the intended implementation: Through the presented approach it is possible to derive essential strategic conclusions for the later realisation of the project, especially regarding the question if the company is able to raise the required resources.

Investigating several industry cases about the adoption of LCC, Korpi and Ala-Risku (2008) point out that the technique is particularly popular due to its provided insights concerning long-term affordability which makes it superior in comparison to other cost estimation techniques. Also Chikofsky and Cross (1990) underline the fact that LCC reduces a lot of uncertainty for software projects by revealing hidden costs. This is of particular importance for SMEs which come not from an IT background due to possible lacks in estimating software costs.

Overall, the offer provides a holistic approach to reliably reveal different kinds of project requirements which are of particular interest for the client. This holistic approach is based on acknowledged and approved methods, which offer detailed application instructions on the one hand, and hints regarding possible problems on the other hand. It has to be considered that the introduced approach is adapted to the individual case of the client and his specific requirements, so that the client receives a study which perfectly fits his needs. Especially the presented experiences of prior software engineering projects demonstrate the appropriateness and validity of the techniques to examine the introduced objectives and, hence, the client’s multiple requirements of daring the development of a mobile B2B application. For the case of changes or enhancements in the client’s requirements, the close communication process during the study ensures optimal customisation of the gathered information. Furthermore, the client is, with the help of the Gantt-chart, always able to identify at which point in the study he is located at the moment.

Due to the information the client receives from the study and the final presentation about the pivotal results, he will be able to make the important decision whether it is more sensible to buy the mobile application or to build and implement it in-house (“build or buy”) (Cortellessa et al., 2008). This decision can be derived by the results of all conducted analyses, which reveal if the client has the required knowledge, structure and resources to build the application on his own while being able to handle the risks. In order to provide a guideline for this decision, the provided study concludes with valuable recommendations for further actions.

Abran, A. (2015), Software project estimation: the fundamentals for providng high quality information to decision makers. Hoboken, New Jersey: Wiley.

Al-Naeem, T., Rabhi, F.A., Benatallah, B. and Ray, P.K. (2005), “Systematic Approaches for Designing B2B Applications”, International Journal of Electronic Commerce, Vol.9(2), pp. 41-70.

Azadegan, A., Cheng, X., Yin, G. and Niederman, F. (2013), “Collaborative Requirements Elicitation in Facilitated Collaboration: Report from a Case Study”, 46th Hawaii International Conference on System Sciences, pp. 569-578.

Babar M.I., Ghazali M., Jawawi D.N.A. and Zaheer, K.B. (2015), “StakeMeter: Value-Based Stakeholder Identification and Quantification Framework for Value-Based Software Systems”, PLoS ONE, Vol.10(3), pp. 1-33.

Baccarini, D., Salm, G. and Love, P.E.D. (2004), “Management of risks in information technology projects”, Industrial Management & Data Systems, Vol.104(4), pp. 286-295.

Barreto, A., Barros, M. and Werner, C.M.L. (2008), “Staffing a software project: A constraint satisfaction and optimization-based approach”, Computers & Operations Research, Vol.35, pp. 3073-3089.

Boehm, B.W. (1991), “Software Risk Management: Principles and Practices”, IEEE Software, Vol.8(1), pp. 426-435.

Byrd, T.A. and Turner, D.E. (2000), “Measuring the Flexibility of Information Technology Infrastructure: Exploratory Analysis of a Construct”, Journal of Management Information Systems, Vol.17(1), pp. 167-208.

Calvert S. (1995), “Managing stakeholders”, in: Turner, J.R. (ed.), The commercial project manager. Maidenhead: McGraw-Hill, pp. 214-222.

Charette, R.N. (2005), “Why Software Fails”, IEEE Spectrum [Online].