Building sustainable business intelligence systems by integrating user-centred methodologies in re-engineering

This paper entails an analysis of the influence of adopting user-centred design in business intelligence (BI) application development. The purpose of the research is to answer the following question: does the integration of user-centred methodologies into BI re-engineering translate to the development of a sustainable BI system? A combination of research methods was applied in the pursuit of answers to this question. This paper surmounted the hurdles of user-developer alienation, through undertaking application development while involving all stakeholders throughout all the stages of development from initiation to implementation, ensuring a collaborative environment and collective idea evolution. While the financial benefits of such stakeholder collaboration were not directly or promptly discernible, the paper covered details of the non-financial benefits easily discernible – such as application acceptance and a sense of ownership among users, which essentially projects to longer life spans for application products. Comparing the findings, in summing up, the research confirmed that, indeed, user-centred design does lead to sustainable BI systems. Further validity and reliability tests undertaken indicated that the findings could well be deemed both accurate and reliable.


INTRODUCTION
BI, the first aspect of this research, is considered one of the latest innovations dominating information technology (IT) investments made by businesses (Lawton, 2006).Its value for business is predominantly expressed by the fact that it casts light on information that serves as the basis for carrying out fundamental decisions in a particular enterprise (Olszak and Ziemba, 2007).User-centred design, the second aspect of this research, is an approach which focuses on usability in the entire development process and life cycle of computer-based information systems (Gulliksen et al., 2003).Users can be defined as the consumers or 'users' of a product (Wallach and Scholz, 2012), and for this research referred to personnel whose organisation role was defined as system analysts.System analysts were herein defined as users because they both utilise the BI product *Corresponding author.E-mail: musakhml@gmail.com;49922238@mylife.unisa.ac.za.Tel: (021) 650 2266, 083 415 0892.
Authors agree that this article remain permanently open access under the terms of the Creative Commons Attribution License 4.0 International License themselves and represent end-users supported by the BI product (Wallach and Scholz, 2012).
The value of BI is compromised by the challenges that arise from a BI implementation that is not entirely understood by the users who make the decisions (Hocevar and Jaklic, 2010).While many reasons have often been identified for this, it was the perspective of this research that such problems originate from the lack of collaboration between application developers and users.This perspective contends that even technical superiority, alone, does not guarantee success and acceptance of an application product.
The active roles of users in the user-centred design approach, performing one or multiple roles as users, testers, informants, co-designers or design partners (Nesset and Large, 2004), are consequently seen to lessen the distinction between users and developers, leading to better understanding and cooperation.The central argument to this research, derived thereof, is that integrating user-centred methodologies in BI application development is likely to translate to the success and sustainability of the application.Sustainability herein refers to the ability of a system to evolve or remain relevant and useful as other details around it change (den Bergh et al., 2008).

Problem statement
Involving potential or actual users of the system in development initiatives is often largely overlooked, while it is often later discovered that beliefs, interpretation, perceptions and requirements differ markedly between developers and users.This virtually means that users will be expected to acquire a system that may be unknown to them.The implications of this are then numerous and serious, including huge costs required to train users, costs incurred in system redevelopment, prolonged system adoption periods, and failure of the system to meet user needs.When this happens, a BI system ceases to be a decision enabler and becomes a decision constraint.This is precisely the problem.

LITERATURE REVIEW
User-centred design in BI might be a relatively littleresearched topic, particularly in an African context.Some consider user-centred design to be relatively young (Karat and Karat, 2003); however, considerable headway has been met in advocating user-centred design and usability studies -which is hard to say for BI.With this advance, though, it has been noted that activities undertaken to emancipate the position of users have not necessarily abided by the actual user-centred design approach (Orr and Nissen, 2006).
A few perspectives have arisen in the attempt to explain this phenomenon called 'business intelligence'.Some express it as a management aspect, some as a technological aspect, and some as a product aspect, while other definitions comprise both technical and organisational elements (Watson et al., 2006).Some have offered more generic meanings which are equally valid, so it therefore means different things to different people.
BI has evolved for use in at least two different contexts: as a system and as a process.As a system, BI has been equated with decision support systems and enterprise information systems (Gray, 2005).As a process, BI has been defined as a process of turning data into information, and information into knowledge, and then into plans that drive effective business activity (Eckerson, 2003).While there are merits to both perspectives, a more complete view of BI is that it can be described as both a process and a system.BI has evolved beyond simply an IT issue, and requires organisations to consider the people and business issues involved (Betts, 2005).The first extensive, detailed works in this line of research surfaced as a consequence of the large-scale adoption of Enterprise Resource Planning (ERP) systems (Caglio, 2003).To date, researchers have shown more interest in ERP systems than BI, with the exception of a few such as Rom and Rohde (2006).Stodder (2013) reiterates the rise in BI and the importance of analytics.He mentions that, due to this trend, it is critical that business and IT bridge their cultures, and improve communication and collaboration.While there is a wide berth between business and IT, the best result can only be achieved if the two organisational entities work together.That argument resonates with this research, and encourages an attitude shift in BI environments from sectional isolation to that of collaboration.
As identified by Pekkola et al. (2006), there still remains a wide gap between methodologies addressing user participation and information systems development methodologies.The numerous user-oriented methodologies (such as user-centred design, and others such as participatory design, co-operative design and Joint Application Development), discuss how to involve users in the system design, yet there is a tendency to merely follow design guidelines such as the Waterfall Software Development Life Cycle, which are usually not aligned with user participation methodologies.The problem here is a lack of flexibility in application development, as entities continue to adopt methodologies that are outdated and no longer return as positive results as when they were developed.The organisations that have BI also have a competitive advantage, but how an organisation defines BI success depends on what benefits that organisation needs from its BI initiative (Miller, 2007).The BI success may represent attainment of benefits such as improved profitability (Eckerson, 2003), reduced costs (Pirttimäki et al., 2006) and improved efficiency (Wells, 2003), as well as a reduction in the amount of time and effort required to deliver a product.
In early 2012, the Gartner group predicted that by 2017, chief marketing officers will outspend chief information officers on technology purchases (McLellan, 2012).Gartner's research indicated that high-tech marketing budgets were growing at more than twice the rate of IT budgets.Should this estimation be accurate by any account, IT cannot afford to wait to improve communication and collaboration with marketing and other business functions, because the value to be realised from the BI investment will have a substantial bearing on technology departments.Not only is such collaboration potentially financially rewarding, it will also prevent the expensive, insecure, difficult and harmful proliferation of non-IT-managed shadow systems -a malpractice which is already known to be taking place in some organisations.

RESEARCH DESIGN AND METHODOLOGY
Owing to its depth of context and the ability to explain phenomena in detail, the interpretivist paradigm was adopted for this research.Interpretivism offers practicality in the sense that those active in the research process socially construct knowledge by experiencing the real-life or natural settings -which allows the researcher to further the understanding of certain phenomena by releasing findings based on first-hand experiences.The positivist paradigm was not chosen because of its lack of subjectivity.
The mixed methods approach, in research, was utilised in data gathering, to leverage the benefits of both qualitative and quantitative methods and improve the quality of research.The quantitative and quantitative methods both have specific weaknesses, but even greater strengths.In any case, no single research methodology is intrinsically better than any other.The use of the mixed methods approach allowed the application of triangulation -which offers multiple options according to which one can answer the research question.Mixed methods allow a broad interpretation and inclusion of issues and strategies surrounding methods of data collection, in terms of questionnaires, interviews and observation.
This research being based on an actual information systems development project, qualify it as an action research project.The aspects that firmly make this an action research project are (a) the need to add knowledge; (b) collaboration; and (c) the need to address an immediate organisational concern.

Data collection
Questionnaires, interviews and observation were utilised in the data collection.The actual data collection activities were preceded by sending a consent form to the potential survey respondents.The consent form served to inform the research respondents clearly of their right of choice in the following aspects: (a) to participate or not; (b) to answer only the questions they want to; (c) to withdraw their responses at any point; and (d) to assure them of their privacy and confidentiality -which is a rather contentious issue in an era of identity and financial breaches in the IT fraternity.
The purposive sampling method was used for participant selection.The choice of the company can also be classified as purposive sampling as it was deliberately selected as the host of an actual projects that motivated this research.The duration of this research was also detected on by the same project, which was a period of 7 months.The company was a large retailer in the Fast-Moving Consumer Goods (FMCG) industry.11 people were identified as potential participants.The profiles of the participants traversed all levels in the BI department, including technical managers, business managers, BI system users, system analysts and developers.Seven of these were available for participation.A further 26 people identified as potential participants were BI practitioners from other companies, not directly involved in this initiative.They were BI users, system analysts, developers, technical and business managers and consultants.As external participants, they were selected based on their prior experiences with undertakings of the same nature as this research.Of these, 15 were available for participation.In total, therefore, 22 participants made up the survey sample.
The pilot survey interviews were carried out on five participants, comprising three system analysts and two developers -all employees of the company on which the research was based.The pilot survey was undertaken by means of the distribution of random semi-structured questionnaires.
One of the aspects commented on in the pilot survey was the length of the questionnaire.The pilot respondents noted that the survey should preferably not exceed 20 questions, and should not take more than a few minutes to complete, as the length would affect the response rate.Respondents also noted that their prohibitive work and social schedules meant that only a few people would manage to undertake the survey more than once.
Surveys were conducted in the form of questionnaires, and distributed after the pilot research.The survey participants could not all respond at the same time; therefore, the spontaneous interviews carried out permitted the application of questionnairerelated feedback.Spontaneous interviews varied widely in length, averaging between 5 and 10 minutes.Both open-and closedended questions were employed in the questionnaires.

Execution of data collection instruments
The questionnaires were distributed using three methods: paperbased (printouts), online (through LinkedIn) and e-mail.The online and e-mail methods were further split into either Microsoft Word attachments or a link to the survey hosted by www.surveyplanet.com.A total of 75 questionnaires were distributed, and 26 responded -which gave a completion rate of approximately 34.67%.The response rate at the company was 73.33% (11 responses out of 15) while online surveys had a response rate of 25% (15 responses out of 60).This is acceptable, considering that online surveys may only be expected to achieve a response return of around 10%.
Informal interviews were carried out in various locations, including outside while walking, in the canteen, in the lift/elevator, and while making coffee.Invitations to the interview were sent to employees of the company by using the corporate e-mail calendar that is part of Microsoft Office 2010, by telephone, and physically, by asking the participants directly.The interviews were recorded on a mobile phone and then stored on a personal computer.The interview questions were based mostly on the responses from the questionnaires and on the principal topic under research.This made interviews quite easy, due to the similarity to the open-ended sections of the questionnaires.
During the interviews it was also important not to limit the participants or steer them in a certain direction too much, because that would defeat the intention of getting their actual perceptions on the subject matter.
The observation method was used in conjunction with unstructured interviews, which exposed the researcher to so many casual observations that some cues needed to be disregarded.

USER-CENTRED BUSINESS INTELLIGENCE RE-ENGINEERING
Detailed herein are the activities undertaken in the BI re-engineering project, and the conjunction points with user-centred design.The project lifecycle was tailored into a custom user-centred design cycle, so that activities at each stage of the project could be identified in the standard user-centred design cycle, as set by ISO 9241: 210 (2010), and the user was considered as a functional component of the application.

Justification for re-engineering
This research was based on a BI re-engineering initiative proposed by the company's executive committee, and it was, precisely, a platform migration from IBM Cognos 8.4 to Microsoft SSRS 2008 R2.Substantial analysis of the benefits of each of the two platforms was undertaken, and the following seven reasons were identified as justification for the migration: i.IBM Cognos has massive licensing requirements, while SSRS is shipped free with the Microsoft SQL server package.
ii.The company already had SQL server licenses for their databases that were not fully utilized; therefore, making use of reporting services shipped with those licenses, would extract a great deal of value from them.iii.Cognos 8.4 was already outdated, and the upgrade to Cognos 10 or higher was overdue.With the current experience, though, the upgrade did not promise enough Return On Investment (ROI) potential.iv.Many users reported unsatisfactory performance from the IBM Cognos report deployments.v.Some uncertainty has also been introduced regarding products support, and whether the Cognos product will remain as currently packaged or will require other tools to work with it.The SQL server, meanwhile, remained a single integrated platform with visible continuity.vi.There are more Microsoft BI developers than Cognos developers, possibly due to the higher popularity of Microsoft products.vii.Microsoft applications are quite open, in terms of connectivity, customization and integration with other applications, while Cognos is more difficult to connect to other applications.

The development process
The development process followed basic steps that started with prototyping, which was compassionately referred to as the Proof of Concept.The same tools used in actual development were used to deliver the Proof of Concept, the primary of which were the following: Microsoft Visual Studio 2008, SQL Server Reporting Services, IBM Cognos 8.4 (for reporting), MDX Studio 4.0, WinSQL, SQL Developer 1.5.5 for Oracle PL/SQL 11g, IBM Informix (database management environments) and JavaScript and HTML 5 (graphical user interface development).
After prototyping, the next venture was report development, which was then followed by the graphical user interface development, both of which were carried out iteratively.
Figure 1 is a screenshot from the BI Development Studio, and it is part of the Proof of Concept.Although the screenshot only shows a single report, the initial Proof of Concept consisted of numerous reports, each with a drill-through to another, as well as sales-based colour application in the columns.

Report and user-interface development
The user-driven product functions refer to aspects, operations, functionalities or features of the product, that were added on request of the user.Such additions formed a major part of the user-centred project, the bases of which are the principles of participatory design.With their involvement in the whole design cycle, the end-user assumed the role of the voice of reason -the people responsible for safeguarding their and their fellow users', interests.
A major part of the project was the determination of requirements with the input of users.In being a re-engineering project, the bulk of the functions already existed in the Cognos platform, and the users required that these be maintained.SSRS, however, is an entirely different platform from Cognos, and delivering these requirements introduced complexities at a totally new level.Users, however, were predominantly unaware of the complexities introduced by seemingly basic requirements.Some of these seemingly simple requests by users that translated to many lines of code included the following: drill-through (the ability to query further aspects of an application, or related application, by clicking on an item on a specific application); colour variances (the alternation of colours returned, dependent on set conditions, numerical or textual); selective PDF/Excel output; divide by zero error handling (situations where a calculation leads to a zero-valued denominator, which raises an error upon execution); field concatenation; lookups; and, date range limits.

Iterative development and testing
The development team and the analysts held regular sessions, in which iterative development requirements were discussed, while all successful stages were noted on a shared platform.All stakeholders were aware of the status of each piece of work.Considering that business champions, who were also present in all these meetings, were aware of the cost implication of non-responsiveness, the turnaround time for each task was exceptionally low.That was one set of indicators of the influence of user-centred design; it eliminates time wastage where user input is required.
User testing was undertaken at every stage of development, changes raised during testing were factored into development, and then the product was moved back to testing, until it passed that level of testing, and only then would it move to the next level.This cycle continued until the end of the development cycle, when the product was deemed correct and accurate -at which point a change control was logged (a request to implement the report in the production environment).The change control was then followed by a move of the report and user interface to production environments (Figure 2; Table 1).

DATA ANALYSIS AND FINDINGS
In this section are details of the findings from the datagathering exercise.Also included are details of the reliability and validity tests undertaken to assure the integrity of the survey instruments.
On the survey distributed to users, classification by respondents indicated that 8 out of 13 questions achieved scores above the 80% mark, and 5 out of 13 in the 60-80% range, which suggested the perceived positive benefits of user-centred design.Classifying the same survey responses per respondent, 5 out of 11 participants classified above 80%, and 6 out of 11 in the 60-80% range.On the survey distributed to developers, classifying the responses per question indicated that 2 out of 13 questions achieved scores above the 80% mark, 9 out of 13 in the 60-80% range, and 2 out of 13 in the 40-60% range.Classifying the same sample per respondent indicates that 2 out of 11 participants classified above 80%, and 9 out of 11 in the 60-80% range.The above statistics suggest that users find usercentred design more favourable than do developers.
Developers have a number of concerns, among them being a belief that user-centred design stifles their initiative, slows down progress, increases project time overheads, and not always the best strategy.A margin of error can be allowed, considering that the users' survey was completed in full -thereby allowing accurate reflection of the results, while there were omissions in the developers' survey -which influenced the results, even though missing results were disregarded in the

Principles of UCD (ISO 9241-210, 2010) Application in the BI re-engineering initiative
Design is based upon explicit understanding of users, tasks and environments.
There was a conscious drive to understand the needs of users and their environments.
Users are involved throughout design and development.
Representative users are actively involved from the beginning, continuously, throughout the entire development process.
The design is driven and refined by user-centred evaluation.
User evaluation started from prototyping, continued throughout the development and adoption cycles.It took on a 'participatory' mode, whereby unit and functional testing was undertaken by members of the development and testing teams, followed by functional and acceptance testing by users.
The process is iterative.
At the end of each development task, testing was undertaken by various stakeholders, and the product was sent back to development whenever any issues were found, or if the product did not meet user requirements.
The design addresses the whole user experience.
The user-centred design approach was not adopted only in user-interface design, but in reporting development as well.The user experience included the experience of the user with cost values, text fonts, validation on selections, and all other aspects of the product.
The design team includes multidisciplinary skills and perspectives.
The project team consisted of individuals from diverse professional backgrounds, with varied skills and perspectives.The design team consisted of ten individuals, with focus meetings held daily at 10 am.
Source: Own Source.

calculations.
Frequency tables drawn from NVivo indicate that the most frequently used words by the respondent users were the following: 'users' (21 times), 'reports' (18 times), 'requirements' (15 times), 'involvement' (14 times) and 'information' (11 times).Four of these five words featured in the developers' most frequently used words as follows: 'user' (74 times), 'development' (33 times), 'requirements' (22 times), 'information' (15 times) and 'involvement' (12 times).An interesting outcome is that four of the top five most used words are common between the users and the developers.This suggests a particular interest in those words, and the words themselves resonate with an inclination towards collaboration.
The following are the word trees that depict the frequency and usage of the words by the respondents (Figure 3).
The word 'user' was the most frequently used for both the developers' and the users' group.While the survey results reveal that developers show a deeper aversion to 'user-centred design', overall there is preference for 'usercentred design', as its influence is recognised since this group mentioned the word 3.5 times more than 'users' (74 times, as compared with 21 times for 'users').
The word trees provide a narrative of the issues that underpin this research, and they mirror the thoughts and ideas of both parties -most of which can be narrowed down to both a lamentation over the state of user-centred design, which has been found to be lacking in many instances for numerous reasons, and expressions of support for the adoption of collaboration between business (users) and IT (developers) (Figure 4).

Validity and reliability of survey instruments
Reliability refers to the consistency with which a measure produces the same results with the same or comparable populations (McDaniel and Gates, 2004).For this research, internal consistency was deemed important, because analysis and deduction was to be carried out on the data, and the deduction can only be accurate if internal reliability is ascertained.Internal consistency was measured using Cronbach's Alpha and computed using SPSS.Cronbach's Alpha is the most widely used measure to assess the internal consistency of a scale (Huck, 2004).The method was deemed to be particularly attractive -not only for its value in ascertaining the reliability of a test instrument, but also because it requires only one set of results (Gliem and Gliem, 2003).This was very positive, as it turned out to be extremely difficult to distribute the survey instrument a second time at the researcher's organisation.
The Cronbach's Alpha (reliability) calculations undertaken on the survey results from developers, as well as from users and analysts, are as below.
The script for the computation of Cronbach's Alpha: Having tested the survey instrument's reliability, it is also important to ascertain the validity of the data (Table 2).Although reliability is necessary, it is not sufficient to validate an instrument, because an instrument may be reliable, but not valid.Validity refers to the degree to which a measure reflects the characteristic of interest (McDaniel and Gates, 2004), or simply the accuracy of the instrument (Huck, 2004).Since it addresses the issue of whether what the researcher was trying to measure was actually measured, it is, therefore, concerned with the integrity of the conclusions generated from the research.A minimum of five participants per variable is generally recommended to apply validity tests (Munro, 2005).

Result from SPSS:
Warning Some or all requested output is not displayed, because all cases, variables or data values passed the requested checks.
A Cronbach's Alpha of 0.7 is generally considered acceptable (Kline, 2005).Yet, other literature suggests that an alpha of less than 0.6 indicates unsatisfactory internal consistency reliability (Malhotra and Birks, 2007) -which implies that internal consistency of above 0.6 is satisfactory.In considering this, therefore, it can be deduced that the survey instruments were reliable and valid.

FINDINGS AND DISCUSSION
Some of the envisaged improvements include prototyping solutions, having solutions tested from the end-user perspective, as well as developers growing other skills  outside of their primary role -such as interpersonal skills to enable them to fit into cross-functional teams.
The viewpoints raised by developers were not so different, except that developers showed an inclination towards technical solutions for current user-centred design problems.Some of the solutions envisaged are as follows: (a) the adoption of agile development methods; (b) the adoption of the latest technologies (which would most likely provide more enhanced platforms for solution development); and, (c) the adoption of products that are the best fit for the requirements of the user, rather than trying to twist existing products to fit the requirements.Developers, similar to users, also cited user involvement and regular meetings (or focus groups) as methods that are relevant to improving the quality of BI reporting.
There was an overwhelming opinion that user involvement practices in BI development projects in general, are not being undertaken religiously -and not sufficiently, either.The level of acceptance of the product indicated that user-centred design can be reliably deemed to greatly improve application sustainability.The user response indicated that they believed that user involvement in this particular research was sufficient; therefore, this research can be classified as a user-centred application development project, and the results be deemed to be a true reflection of the influence of user-centred design in a BI initiative.
It can further be deduced from the survey that users are considered (by both developers and themselves) to be generally more conservative than futuristic, as their input in application development is mostly based on past experiences, rather than future expectations.While analysing a current application, a user is believed to more likely identify issues that should be addressed, rather than what functionality or evolvement the application should take in the future.It is for this reason that some developers believed that user-centred design might be counter-innovative.
The opportunities identified, though, far outweigh the risks.Users are expected to accept ownership of the application, which reduces the overheads on development teams, and the elimination of user resistance in future project plans.The collaborative nature of user-centred design offers more creative design potential; that is, meeting users' needs can be ascertained, because an understanding of the application means that users will be in a better position to correctly interpret report data.Moreover, the involvement of users may actually raise awareness of opportunities they did not realise were available.This implies that, contrary to the earlier findings, user-centred design may lead to innovation -should it be undertaken prudently.
As technology continues to evolve, future studies could be on the new technologies.Concepts such as cloudbased BI, self-service BI, mobile BI, big data and predictive analytics are potentially the standard of the future.Embarking on studies to explain the phenomena to BI consumers could potentially have considerable impact in the way the technologies are adopted and used by the host organisation.While these concepts all offer attractive opportunities for further studies, even bigger potential could lie in offering BI service from a business rather than a technology perspective.All these indicate that the opportunities for further study are altogether limitless.

LIMITATIONS OF THE STUDY
Not only did a relatively small number of participants in the survey make it harder to generalise the findings to the larger community, but it also made statistical analysis harder.However, as statistical analysis was carried out in conjunction with qualitative analysis, it warrants that the greater the number of respondents does not equate to higher validity.Furthermore, reliability and validity tests carried out indicate that the survey instruments and the survey data were both above the thresholds, therefore can legitimately be deemed accurate.
In addition, this study does not outline the actual time and human resources required to attain a comprehensive and effectual user-centred focus, particularly as organisations vary in size, maturity, core business and resources structure.As such, it will be particularly useful in organisations with structured technical and business teams, but evidence has not been gathered to indicate whether or not it will be equally applicable to unstructured organisations.Differences in organisational complexity and dedicated human resources make it nearly impossible to determine actual measures required to attain usercentred focus, and this study was no exception to this.
This research relied on self-reported data, as with many studies of this nature, which cannot be independently verified.Therefore the researcher was compelled to take the opinions of the survey sample at face value, be they in questionnaires, interviews or focus groups.Selfreported data is exposed to such limitations as selective memory (remembering or not remembering experiences or events that occurred in the past) and exaggeration (representing outcomes or events as more significant than is actually the case).Self-reported data is, however, not expected to have distorted the outcome of this study, as triangulation of methodologies was undertaken.The inclusion of the practical aspect in the study also provided a verification mechanism for all data acquired from survey samples.

Conclusion
The evidence of success of a BI reporting application is acceptance and adoption by users.Getting users to accept an application is often a long and daunting task which is not always successful.The adoption of the BI application covered in this research was unhindered, and received positive reviews from all stakeholders.The process pursued, and the quality of the product, were lauded -both of which were the culmination of a process of collaboration and iteration.This research has offered a practical base for the integration of user-centred design and BI, which has largely been non-existent, particularly in an African context.While it has been found that neither user-centred design nor BI is new or novel concepts, they have been covered in theory but not practised in Africa.This research has not only substantiated the relevance of UCD in a real-world setting, but also set precedence for further and more exhaustive studies.
The input from the survey sample indicated that all stakeholders (both users and developers) would like user-centred design to be adopted as the development strategy.It also showed that not only are users willing to assume ownership of applications should collaboration be undertaken, but also that they would like to see continuity of the BI application as an ongoing concern.This research provided further insights in the field of BI; it is crucial that technical resources (developers) acquire interpersonal skills to facilitate better communication and relationships with business teams.Furthermore, it is imperative that the traditional cultural chasm between business and IT teams be broken to eliminate the animosity between the two.It would also be prudent that organisations establish BI projects at an organisational rather than departmental level, which ensures that projects are not exposed to the dynamics of inter-departmental relationships, while nurturing collaboration?
Altogether, user-centred design is clearly prudent practice.However, it comes at a price.User-centred design alone is not enough, and requires combination with the relevant technical expertise to meet the users' needs.Such needs are not always an easy feat to achieve, as some users have extremely demanding and complex requirements.Yet, this research found that the complexities are a cost far outweighed by the prize.It can be concluded, thus, that the integration of user-centred design does lead to the development of sustainable BI applications.

Table 2 .
The results of Cronbach's Alpha reliability test for users and developers.

group Cronbach's Alpha Cronbach's Alpha based on standardised items No. of items
Source: Own source.