Building a Business Case for Test Automation

Are you part of an IT department or test team interested in implementing test automation for JD Edwards EnterpriseOne? Is senior management reluctant to approve spend without a detailed, costed proposal? If the answer to either of these questions is yes, then this blog is for you!

Knowing the advantages of a solution and being able to translate them into a compelling business case are two different things. Decision makers are going to expect a cost/benefit analysis at the very least; which may form a part of a formal review process.

When it comes to building a business case, we’ve identified six key components:

  • Executive Summary
  • Describe the business problem and need
  • Outline the objectives for the new test automation software
  • Assess the potential risks
  • Define the implementation approach for on-boarding the new software
  • Outline the Commercial Plan & ROI

Executive Summary

For time-sensitive execs, this is your first, best chance to convince them to read on. It’s a bit like the covering letter on your CV. If you can’t pitch the idea in a concise, compelling way you may lose your audience early on.

Avoid too many words at this stage. Keep it short and simple and avoid technical language – especially if non-technical stakeholders are involved. State the business challenge that needs to be overcome, what benefits you expect to achieve and why your chosen solution is the best one for the job.

Include a summary statement of the costs and the projected ROI to the business over a 3-5 year period, but keep it short. Remember; although we’re including this section at the beginning, it should be the last thing you write.

The Business Need

Your needs analysis is an important part of the business case. If the problem that needs to be addressed is not easily identifiable, and quantifiable in terms of its impact on the business, you run the risk of hitting the “I don’t see the problem” barrier.

Break your analysis down into two simple sections. First, identify the problem. Second, outline the benefits to be gained from fixing the problem.

In terms of the problem, clearly define what it is, why it exists, who is affected (and to what extent) and what happens if it isn’t addressed. Remember to include specific examples to support your assessment; such as:

“Our analysts spend an average of xx hours/days per month on repetitive manual testing; 60% of that time could be saved if test automation were introduced.”

When you are stating the benefits to be gained, try and be as specific as possible. The ability for your analysts to “deliver more for less” via process automation has implications for staff costs, productivity, efficiency, risk management, protection of IP and the elimination of knowledge silos.

Setting Objectives

State clearly what the implementation of the test automation solution should achieve for the company. Whilst some objectives may be difficult to accurately quantify at the outset, others should be Specific, Measurable, Achievable, Realistic and Timely (SMART). This hard data will verify the value of the software and will help to justify the investment, in business terms, to the senior management.

For example: “Improve staff morale by automating repetitive tests” or “accelerate the time to deliver change events” may not be as compelling as: Automate 70% of regression tests within the purchase module by 30th October, or reduce time spent annually with systems auditors by 38%.

Where possible, add detail to elaborate on a given objective and the rationale behind it. For example:

“Currently, our full regression test for one module takes two weeks to run. Automating JD Edwards regression testing would take one day to run and two days to analyse the results. This would reduce our regression testing resources by seven days (70%). As full regression testing of this module is required five times a year, this equates to 35 days of testing saved per year on just this one module. Extrapolating this out to multiple modules will provide the company with savings of over 200 testing days per year.”

Risk Assessment

Your business case cannot just focus on the positives. Any IT investment project involves a degree of risk, so your assessment should include due diligence. Common types of risk to consider include:

Operational: This group includes two main risks; user adoption and reliability. Both can be mitigated by implementing a reliable solution that is user-friendly and easy to navigate. Also, do not forget to include in your business case a note about staff training necessary for faster user adoption.

Technological: A general set of IT risks and warnings include concerns over support, functionality, compatibility and compliance. You can mitigate these risks with a system that is fully featured, configurable and adaptable to changing business demands.

Financial: As the cost of a solution increases, so does the risk. Consider set-up and maintenance costs, along with any add-ons, mods or extensions that might be required. Financial risk can be mitigated by choosing a solution that is available on a SaaS basis, eliminating the up-front capital expenditure.

Implementation Plan

Your business case should assume you secure the project and include a detailed implementation plan. The presence of a critical path and resource allocation will help provide assurances that the project has been thoroughly thought through.

Stakeholders will want to know how long the project will take and what skills and knowledge will be required for a successful implementation. They will also want to see clear milestones and a process for error correction if required.

Commercial Plan & ROI

No business case would be complete without a financial breakdown and an analysis of ROI. Alongside any capital or operational expenditure, you should highlight the financial savings expected from project.

It goes without saying that this is an important part of the business case as it will determine if the project is financially viable. Calculating ROI can be a complex process, but is essentially the annual benefit realized, divided by the total investment, expressed as a ratio or percentage.

The project will need to be fully costed and include sources of funding, cash flow and an illustration of returns over the short, medium and long-term.

DWS has experience of supporting customers throughout the scoping, evaluation and budgeting phases of a wide range of projects. If you need help with developing your own business case, contact one of our consultants now on

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to our blog

Our Customers

Need Help?

Marcoms House
Abbey Barn Road
High Wycombe
HP11 1RL

UK: +44 (0) 1494 896 600
US: +1 888 769 3248
ANZ: +64 (0) 9427 99 56