This worksheet is one of two worksheets that together enable you to conduct a cost benefit analysis alongside your architecture analysis. It is, therefore, an optional part of SARM, but the approach, and guidance on how to apply it, are provided in the optional cost benefit analysis section of the User Guide.
While it is beyond the scope of SARM to discuss benefits mapping and benefits realisation methods, this worksheet allows a choice of three different methods for estimating and allocating tangible financial benefits to the solution. They require you to have an overall understanding of total benefits associated with your new or updated system or service. This information is captured in the box in the top-left corner of the worksheet, with input data in cells C3 to C5. Some new solutions will generate a one-off financial benefit. If this applies to your project, enter the value of the one-off benefit in cell C3. Some projects will realise an annual benefit, and if this applies, enter the annual value of the benefit in C4. Of course, projects can achieve either or both types of financial benefit. Cell C5 captures the period across which you wish to calculate total benefit (which will be compared with total cost of the competing solutions over the same period). Indicate the number of years you wish to use for your cost benefit analysis in cell C5.
Cell C6 will then calculate the ‘Maximum benefit’, representing the result of the simple calculation of totalling the benefits across the number of years. It is called ‘Maximum’, because it is assumed that this is the highest level of possible benefits that can be achieved only if all of the requirements will be fully realised. If any solution option is unable to satisfactorily achieve some requirements, then it is reasonable to assume that some of the benefits will also not be realised.
The remainder of this worksheet is largely concerned with apportioning the ‘Maximum benefit’ across the set of requirements that have been documented in the ‘Context’ worksheet. Each scenario occupies a row with its description from that worksheet replicated in column B, and the risk Impact, also from that worksheet, replicated in column C. Column D, entitled ‘Weight’, shows the corresponding numeric value of the Impact from the Risk Model.
Derived, Assigned or Hybrid benefit
This is where we come to the choice between three methods of apportioning benefit across the requirements. If a detailed benefit map has been developed by the project team, following the adoption of a benefits realisation method, then it should be possible to allocate the Maximum benefit amount (as shown in cell C6) across the set of requirements. Some requirements are likely to derive more benefit than others, and so column F, ‘Assigned Benefit’, can be used to allocate a specific financial benefit to each requirement. To adopt this method of apportioning benefit, you should select Assigned in cell F5. This will cause the ‘Total Benefit’ column (column I) to pick up the values you’ve entered in ‘Assigned Benefit’ column (column F). Note that the total amount allocated across the entire column will need to add up to the Maximum benefit amount displayed in C6, and if there is a difference between these amounts, a warning message will be displayed in row 7. Be aware that you may have up to 100 requirements, so agreeing a separate benefit amount for each one may require a considerable amount of work.
An alternative to this approach that is available in the SARM spreadsheet tool is to allow the levels of impact that have been assigned to each requirement to act as a weight in the distribution of the Maximum benefit across the set of requirements. The assumption here is that if failure to achieve a requirement will have a greater level of impact, it is likely that a greater amount of total benefit will be at risk. The simple (but somewhat dangerous) approach adopted here is to assume that the amount of benefit attributable to each requirement is in the same proportion as the level of impact as defined in the Risk Model. How reasonable this assumption may be is for you to decide, and you can see the consequences of it in column E (‘Derived Benefit’). It is for you to determine whether this approach will give you a good enough approximation to make the cost benefit analysis valuable, or whether you have to explore the benefits that will be derived from each individual requirement in detail.
A third option available to you is a hybrid of the other two approaches. If you have assigned a benefit amount to a requirement in column F (‘Assigned Benefit’), then that amount will be adopted as the tangible benefit for that requirement in column I. If you have left the assigned benefit with a value of 0 (or left it blank), the system will allocate a proportion of the total unassigned benefit (the difference between the total maximum benefit and the total assigned benefit) using the same method adopted for the ‘Assigned’ approach described above. The weight that will be applied is shown in column G, and you also have the option of overriding this weight with a different value. This can be useful, for example, if you have a requirement that might be really critical, and therefore have a high level of impact, but derives no financial benefit. Some security requirements fall into this class – failure to achieve them would be catastrophic, but great success might not lead to increased income. The result is a hybrid of the two approaches, allowing you to assign some key benefits to specific requirements while letting the system apportion the rest of the total benefit across the remaining requirements weighted by Impact.