Research from Vanson Bourne, which questioned about 600 IT decision-makers, including 100 in the UK, found that 48% of software testing and development projects are outsourced and one in four fail to achieve the set goals.
The research findings revealed that 31% of outsourced projects have run into service level or time issues and 23% have failed to deliver on the final requirements. Over half (57%) of CIOs even described some of the outsourcing as “unmanageable, an embarrassment, a nightmare or a total failure”, said the research report.
Changes to requirements are a major problem, with 55% of CIOs citing too many changes during the project as the main reason for project overruns or failure to deliver on the final requirements. Despite this, 47% of organisations change the specification of work at least once a fortnight or more frequently.
More on software testing
CIOs find it difficult to accurately outline requirements at the start of a project, with 81% of respondents not confident that they can clearly document and communicate project requirements to outsourcing suppliers at the outset.
Less than half use dedicated requirements software, with the majority relying on spreadsheets such as Excel and written documents such as Word to capture their requirements.
Over a third (37%) of IT decision-makers said outsourcing service providers use changes to drive profitability, with 96% of CIOs stating that unpredicted costs arise due to change requests. Only one in three felt those costs were fair.
Chris Livesey, vice-president at Borland, which commissioned the research, said the findings highlight that relatively poor outsourcing results are often caused by a lack of investment in the processes for requirements management and test specification.
“The results could be greatly improved by investing in a much clearer statement of requirements and their associated test cases early in the project, enabling both the end client and the service provider to more accurately estimate the project schedule, risks and costs at the beginning of the contract," he said.
"This transparency is relatively straightforward to achieve through a combination of discipline and dedicated tooling, which also allows a much stronger element of control in how those requirements and test cases evolve throughout the project.”