35% of the IT budgets wasted due to rework from insufficient clarity

30 Apr 2015

1

Upto  to 35 per cent of IT budgets are wasted due to rework caused by poor definition and management of requirements, says a new report jointly prepared by
IT Lifecycle Assurance provider Maveric Systems and  global BPO and IT  research & analysis firm NelsonHall.

The study,conducted across Tier 1 and Tier 2 banks with 50 IT executives and 50 business executives in UK, Benelux, Nordics, Middle East & Africa, and Asia Pacific, reveals that gaps exist in understanding the scope of the project between business heads and the IT team, right from the early stage where business requirements are defined.

The report additionally identifies the origin of these gaps; during an IT adoption cycle, the business heads and IT teams usually get into a conflict where the final outcome does not meet the business requirements; 6 out of 10 times, one would find large gaps between the solution and the stated requirements.

Ideally in an IT project, 25 per cent - 28 per cent of the time should be spent on writing requirements; in reality, less than 10 per cent of the total time is dedicated to this exercise. Moreover, poor definition of requirements does not meet the vision of any project thereby causing the gap to grow.

Underestimating the consequences of poor business requirements definition always proves costly for the organisation. Maveric's data over the last 10 years indicates that in 50 per cent of the projects, up to 35 per cent of the IT budget is wasted due to rework caused by poor definition and management of requirements.

Defect prevention is always better than defect detection, therefore helping corporates optimise their IT spending and time spent on adopting IT systems. 'Requirements assurance' has therefore become a key focus area for organisations today, to optimise utilisation of funds and resources, and thereby meet the vision of the project.

'Requirements assurance' is where the 'purpose' and 'business needs' are defined clearly; business heads define their requirements to the IT team, and the IT team in turn evaluates and validates these requirements, before moving to the next stage.  

The purpose of this study was to establish current practices in requirements assurance and the level of satisfaction, within the Banking sector.

The study reveals that while a reasonable effort goes into defining high level requirements, very little time and effort goes into capturing detailed requirements from the very beginning of the project.

Some other key findings of the report show that:

  1. Only 50-60 per cent of business and IT heads are satisfied with their organizations' requirement management practices
  2. Due to poor requirements definition, development time goes up by 25 per cent in transformation projects, and by 19-29 per cent in business-as-usual engagements
  3. 23 per cent of the projects are either deferred or not implemented due to poor definition of requirements
  4. A 12 per cent increase in the IT budget is needed to fix these defects originating in the requirements definition and add 10% to cost base
  5. Banks spend 5 per cent of their overall IT budget on Requirements Assurance

''This report reveals that over 23 per cent of the projects are either deferred or not deployed due to the poor definition of business requirements," says John Willmott, CEO, NelsonHall. "This translates to the amount of money and time that is wasted due to poor definition and management of business requirements. Technology programs have become a priority in every CIO's agenda today. Therefore, there is a compulsory need for a change in approach to deliver critical quality goals and, business requirements definition management is the starting point''.

Surya Vangara, senior vice president, per cent will save up to 35 per cent of the budget that is wasted due to rework caused by poor definition and management of requirements. The math is clear'', he said.  

Data reveals that there is a need for domain-embedded requirements definition / validation tools which will aid in eliciting and defining requirements as well as building an agreement between three key stakeholders i.e. business, IT and the technology vendor, right at the front-end of the program.

Additionally, as these business requirements are extremely dynamic, requirements management and stability of these requirements throughout the lifecycle become extremely critical.

 

Business History Videos

History of hovercraft Part 3...

Today I shall talk a bit more about the military plans for ...

By Kiron Kasbekar | Presenter: Kiron Kasbekar

History of hovercraft Part 2...

In this episode of our history of hovercraft, we shall exam...

By Kiron Kasbekar | Presenter: Kiron Kasbekar

History of Hovercraft Part 1...

If you’ve been a James Bond movie fan, you may recall seein...

By Kiron Kasbekar | Presenter: Kiron Kasbekar

History of Trams in India | ...

The video I am presenting to you is based on a script writt...

By Aniket Gupta | Presenter: Sheetal Gaikwad

view more