If you want to show ROI to management, do not unit test, unless you suspect certain specific units of being defective. Instead, test features, aka use-cases, aka scenarios, that will actually occur when the software is being used in the field. The ROI from these is threefold:
it catches bugs that are likely to be encountered in actual use, clearly preventing far more expensive maintenance and support issues. [see below]
it automates some or all of the acceptance-testing process, which saves considerable time and manpower
it illustrates how the components of the software are supposed to be used and are supposed to interact, which makes it much easier for new developers to understand the software system, thus saving time and money on training
I am not a fan of blind unit testing except for the most exacting of software projects. 100% code coverage may be conforting, but it may provide no significant ROI in a practical sense. I'm a big fan of TDD-style feature testing - it is easy for management to comprehend the impact of "if the user enters 1000 in the Crisis field, selects Travesty from the menu, and then clicks the Exponential button, we get an integer overflow error in the database update code", than it would be for him/her to imagine why anyone would care that "uspCrisisManagementFieldPlacementCalculator cannot handle input values over 999 in certain operational modes". It may be the case that the correct way to fix this particular problem is to disallow values greater than 999 in the Crisis field, depending on exactly what your application is supposed to do. In other words, mere unit testing runs the risk of testing things that cannot happen and also of generating "fixes" that ignore the actual context of use. Striving for 100% code coverage, as is often lofted about as a goal of unit testing, may waste serious amounts of time and money, both by testing things that cannot actually happen in practice, and by encouraging fixes and scope creep that do not consider the context of use.