In the last few years the IT industry has undergone phenomenal change through the deployment of technology and process cultures to gain competitive advantage and market share for organisations. The organisation of the future will be required to create an IT environment which can adapt within expected timeframes at all levels of the organisation, in strategic direction, tactical deployment and operational capabilities.
Financial institutions predominantly focus on product delivery to clients, but legislative, political and global external factors impact heavily on information technology. By default, all of this impacts on the quality of software solutions that are delivered. In organisations where software is a critical business component, and where the software delivery results contribute to the success of the organisation, IT departments often launch programmes to attempt the improvement of the quality of their software.
Research was conducted in the IT area of a South African financial organisation using the case study method to determine the adverse impact of business priorities on IT software development quality. The research showed that quality is planned into a project, regardless of whether it is in the delivery to the client or in the code itself. Implementing the necessary processes and methods enables IT to successfully analyse and design workable and technically feasible solutions that are sustainable in the long term, regardless of time pressure. Technical planning and change control processes are of extreme importance and reduce the impact of business priority changes on IT software development quality.
IT software development needs a very diverse application skill-set that is used to deliver a very exact result. It needs creativity, skills and expertise from the IT specialist to successfully analyse and design a workable and technically feasible solution that can be sustained in the long term. The solution not only has to fit into the IT software architecture strategy, but also needs to be fast, effective, efficient and of good quality.
Unfortunately, when timelines are tight, the fastest possible solution is supplied – often at the expense of quality. A quick solution usually results in an increase in production support effort later on, because the necessary attention was not given to quality, process and accuracy. The lack of IT software quality could adversely impact on the quality of the entire business.
The research problem:
“Business priorities adversely impacting IT software development quality”.
The research question:
‘How can IT software development quality be maintained regardless of business priorities changing?’
Specific objectives of the research:
For the survey, 30 employees from various functional roles were randomly selected to represent the sampling frame. Employees were selected from the following research strata:
Questions were categorised under:
The design of the survey was a descriptive survey as opposed to an analytical survey. A descriptive survey according to Hussey & Hussey (1997) is frequently used in business research as an attitude survey. A Survey of 75 statements was set up with response options of:
A quantitative (positivistic) business research was done by using a survey. The results were studied to make inferences about tasks and processes during software development projects, with specific focus on software delivery quality.
Action research (as a part of case study research) was done in the form of information systems research. Due to the fact that information systems research has often been viewed as residing within the province of technology (Galliers & Land, 1987), the analogy can be drawn that the same norms would be applicable to ‘systems-related research’, which refers to all disciplines pertaining to the management of information technology. The crux of the matter, however, lies embedded within the context of an observation made by the above-mentioned two authors, where they suggest that it is important to extend the focus beyond the IT topic to include both behavioural and organisational considerations. They refer to information systems being impacted by the organisation and the people they serve.
According to Emory & Cooper (1995) stratification is almost always more efficient statistically than simple random sampling and, at worst, equal to it. With the ideal stratification, each stratum is homogeneous internally and heterogeneous with other strata. To ensure that each identifiable stratum of the population was taken into account (Easterby-Smith, Thorpe & Lowe, 1996), the respondents were selected from all the different IT areas.
The target population areas were specifically chosen in order to validate the practicality of the concepts as presented here. The risk of bias, which cannot be statistically eliminated, is recognised by the author, based on the very definition of the target population as well as the number of respondents selected.
The survey was based on the well-known Lickert scale which is a summated rating approach. Respondents were asked to respond to questions or statements according to the gradation most suitable to their opinion or feelings. The Lickert scale was chosen because it can be used in both respondent-centred and stimulus-centred studies. The advantages of using the Lickert scale according to Emory & Cooper (1995) are:
Replies from the respondents were collated and statistically analysed with the following results where all or the majority of respondents agreed:
Values and Ethics
Organisational Culture
Software Development
Development Projects
Quality
Conclusion
From the survey results it is evident that the majority of the respondents agree with the overall findings of the research done on the different topics. Most of the minor issues where the target population do not all agree should by default be resolved as the organisation’s IT maturity increases.
The research proves that business delivery pressure and prioritisation definitely impacts on the quality of software that is delivered by IT to the business. The research findings will contribute to the existing body of knowledge within the financial IT industry in terms of re-confirming already known problems, and also in terms of the integrated problem that is created across the organisational areas when IT delivers sub-standard business solutions.
From the research it is evident that business strategies impact heavily on information technology and the services that IT supplies to the organisation. Pressure exists around successful and quality IT delivery to business, and also successful and quality business delivery to clients.
IT should focus on three kinds of improvement initiatives (Figure 1). On a high level this model will enable IT to deliver quality software while prioritised business delivery is met. It will also advance organisational maturity and growth.

Figure 1: IT Improvement Initiatives
It is extremely important that IT gets, and stays in touch with business delivery plans and strategies and continually makes sure that the whole organisation’s IT community understands the business system solutions planned in the short, medium and long term. This will ensure that all teams work on common goals and it will be easier for all concerned to “stay on the same page”. The IT team of an organisation needs to become more transparent, measurable and aligned with the larger objectives of the business.
It is very important that IT management:
The correct processes and work methods should be in place so that during a development life cycle, specific quality attributes can be selected for every build project based on their importance to the project and their ability to be quantified. Measurements for each metric should be defined and their usability and applicability discussed with the project teams so that measurements are being done on a regular basis. Achieving success in these measurements will contribute to the improvement of quality of software. A software strategic plan will guide the software quality improvement process and the measurement thereof.
Often it is found that, even though technical change management is in place at an organisation, the total change strategy and end-to-end processes in the IT environment need to be analysed, defined or redefined and formally implemented or changed.
The biggest asset of an IT organisation is its people. Their creativity and productivity ensure the success of the division and often also the organisation. Proper controls and software quality contribute a lot to the success of an IT department. To successfully implement and change strategies, commitment must exist throughout the organisation. The people of the organisation must lead change, overcome resistance, grow creativity and build winning cultures.
It is critical that the right people must be recruited in IT, and powerful teams must be built that will foster the values of the organisation and create a learning organisation. A successful organisation must — and does — continually adapt and learn in order to respond to changes in the environment and grow as an organisation.
Organisations should have a solid organisational development strategy and plans. The ability to cope with change and transformation resilience lies at the core of an organisation’s leadership and culture transformation strategies.
Olson (1982) was one of the first IS researchers to refer to the relationship between IT and organisational culture. It is important to skill up IT resources to be able to manage the social structures in the environment while being able to do traditional IT tasks. With the correct skills, IT people will be able to deal with ‘peripheral’ issues while timeously facilitating solution delivery. It is critical that resources are equipped to deal with a changing dynamic environment where they can expand their technical and business knowledge base and become more versatile for the organisation of the future. IT delivery should be “managed” from the top down and a “team” quality culture needs to be created.
IT management should select the right project, the right people and the right goals for a winning combination. Critical projects with adequate and correct resources produce better results.
Quality client products depend on quality software. Quality is important, but not always easy to define and measure. Kitchenham (1989) notes that quality is hard to define, impossible to measure, but easy to recognise. According to McConnell (2003) quality is transparent when presented, but easily recognised in its absence.
It will be almost impossible to convince business areas of increased development time in order to dedicate time to quality and risk, but project and development managers should include, at a minimum, consideration of the following into the estimates given to business:
Risk and quality attributes can be used to derive a core set of metrics relating to the development process and the life cycle products - such as requirement and design documents, code and test plans. From a pragmatic description of software quality, organisations should strive towards four goals: requirements quality, product quality, testing effectiveness and implementation effectiveness.
Process gates should be implemented to ensure that documentation regarding system requirements is complete, unambiguous, and understandable. Requirements must be stabilised as quickly as possible, and should be traceable from their source to the software requirements document and then through design, testing and implementation. If requirements are not properly defined the end result of the software build can be an unsatisfactory final product.
Locate and repair problems proactively. Error detection early in the development life cycle instils quality in product delivery and also improves the quality of testing done by testing teams. Error rate, error classification and mean time to repair should be measured, managed and published by the project with supporting processes to immediately rectify problem areas.
In conclusion: with the correct IT framework, quality can be planned into a project, regardless of whether it is in the delivery to the client and business, or in the code itself. Tight timelines and changing priorities is a part of ‘normal’ IT life as we know it. Technical planning and technical change control are very important, and will go a long way towards reducing the impact of changed priorities on IT software development quality.
Successful delivery criteria are: the satisfaction of a specific business need, with a technical solution that fits into the IT software architecture strategy, and that is fast, effective, efficient and of GOOD QUALITY.
De Beer, S. P. (2008) Business Priorities Adversely Impacting IT Software Development Delivery. A dissertation submitted in partial fulfilment of the requirements for the degree of Master of Commerce in Project Management at the Cranefield College of Project and Programme Management.
Hussey, J. & Hussey, R. (1997) Business Research: A Practical Guide for Undergraduate and Post Graduate Students. Macmillan Press Ltd: Houndmills.
Galliers, R.D. & Land, F.F. (1987) Choosing Appropriate Information Systems Research Methodologies. Communications of the ACM. November. Volume 30. Number 11.
Emory, C.W. & Cooper, D.R. (1995) Business Research Methods. Fifth Edition. Irwin: Homewood
Easterby-Smith, M. Thorpe, R. & Lowe, A. (1996) Management Research: An Introduction Sage Publications.
McConnell, S. (2003) Rapid Development. Microsoft Press: U.S.
Boehm, B. (1989) Software Risk Management. IEEE Computer Society Press:U.S.
Olson, M. (1982) New Information Technology and Organizational Culture MIS Quarterly, Volume 6. Special Issue: [1982 Research Program of the Society for Management Information Systems].
Kitchenham, B. & Pfleeger, S. (1996) Software Quality: The Elusive Target. IEEE Software.
Sarnell de Beer
The reproduction, adaptation or broadcast, without permission, of any articles
or photographs published in this
publication, is forbidden and copyright
is expressly reserved for Test and Data Services (Pty) Ltd.
Opinions expressed by contributors are their own and do not necessarily express the opinions of the Publisher, Editor or members of the Editorial Panel.