There's no question that a commercial Requirements Management tool is very useful;
but, can it pay for itself at your company? In this article we’ll look at a model
to help you calculate ROI on Requirements Management tools.
Overview of ROI
Return On Investment (ROI) is a popular method of measuring the success of process
improvements and IT investments. It is a measure of the dollars returned on dollars
invested. As Jeffery E. Payne points out in his article "Quality Meets the CEO:
How to Get Management Buy-in," ROI is an effective approach for arguing the need
for, or demonstrating the success of, process improvements and IT investments.
Though there are a number of methods of calculating ROI, one straightforward,
simple to understand method is the Benefit to Cost Ratio, which is simply dividing
the benefits in dollars of process improvement or IT investment by the costs.
Benefit to Cost Ratio = Benefits/Cost. So, a Benefits to Cost Ratio of say, three,
would mean that for each $1 spent on the cost of process change and IT, $3 in
benefits were realized.
Let's look at how to do a Benefit to Cost model for process change and IT investment
of putting a requirements management tool in place at your company. Though this
model was developed in conjunction with the rollout of a commercial tool, it should
be readily adaptable to development and rollout of "home grown" tools.
Requirements Management Tools
|| In doing an ROI assessment, typical
sources of cost include:
Typical benefits that are considered in an ROI assessment include:
- IT investments, including ongoing maintenance
- Training staff in new processes and IT tools
- Consulting needed to assist process change and IT installation
- Recurring cost associated with new process and IT
- Increased revenue, e.g. increased sales, or sales margins
- Retention of sales that would otherwise have been lost
- Reduction in operating expense, e.g. daily time savings, eliminated rework
Requirements Management tools are to requirements what Defect Tracking Tools are
to defects. They provide an environment for, and database approach to, managing
large numbers of requirements related in potentially complex
ways (traceability). Requirements tools provide continuity through time, across
projects, through staff changes, and through company re-orgs. They are a corporate
memory for requirements.
In a project, setting a Requirements Management tool is used in a number of contexts:
For a large company, dealing with thousands of requirements, moving to a database
approach to managing requirements, allows a metrics-based management of requirements
that is simply not practical with paper document-oriented approaches.
- Planning the scope of a release, or a series of releases (key in iterative,
- Managing plan execution: who is responsible for what, when
- Tracking project status
- Change control of scope, particularly in evaluating the impact of proposed
changes (this is where traceability of requirements is critical).
Calculating the ROI
No question that a requirements management tool is very useful, but can it pay
for itself at your company? In his paper Calculating Your Return on Investment
from More Effective Requirements Management, Dean Leffingwell advances this
model for estimating ROI (numbers are from his example ):
One can then make an argument that if the requirements management process was
improved by say 10%, that is a cost savings of $504,000 x 10% = $50,400. If the
cost of process improvement (e.g. training), plus tool purchase was a total of
$19,900 (again, numbers from his example) then the Cost to Benefit Ratio is $50,400
/ $19,900 = 2.53.
The model I will present here is a bit different from Leffingwell’s; it will provide
specific improvements one might expect from installing a requirements management
tool. I will then try to quantify the benefits from that perspective. The model
is based on one I developed for a company of about 500 R&D staff, 1000 employees
overall. The tool, a commercially available product, was deployed in four cities.
The ROI assessment was done about 1.5 years into the rollout.
Assumptions and Conventions
We begin by making a number of working assumptions and conventions that will
be used throughout the ROI model. The model is developed in an Excel spreadsheet.
Cells with black text are ones for which you must input values that make sense
for your company.
Cells with red text are ones with values computed via some formula.
Cells that are gray filled have values that are subjective.
These fields are the main source of uncertainty in the model. In interviewing
staff as part of the rollout, the values for these fields varied widely.
We begin by calculating the cost of a fully burdened employee, per work day, per
hour, and per minute. By "fully burdened" we simply mean the total cost
the company: salary + total benefits. As a rule of thumb, the fully burdened cost
is usually about 1.5 times the salary.
Next, we capture the actuals in terms of numbers of requirements that were entered
into the requirements management tool as of the date of the ROI assessment; about
1.5 years after initial rollout. Of the approximately 5000 requirements entered,
about 1000 had already been implemented and shipped as part of some project, and
some 200 had been rejected, meaning a decision had been made that these requirements
would never be addressed in any future release.
An ROI assessment must be done for a fixed period of time; both the cost and the
benefits must be calculated for the same fixed period. This study was done about
1.5 years into the rollout of the new requirements management
process and tool.
Click Here to Read the Full Article
First appeared at StickyMinds.com
About the Author:
Richard Denney is a software process management consultant, emphasizing requirements
and testing management. Richard is an affiliate of TeraQuest Metrics (www.TeraQuest.com),
a leader in CMM consulting, holds a BA and MS in CS from the University of Texas,
and is certified with the Product Development and Management Association. Contact
info: visit http://www.rdenney.bizland.com
or e-mail email@example.com.
Read this newsletter at: http://www.itmanagementnews.com/2003/0826.html