Calculate the ROI of more efficient Demand Management

Dean leffingwell

Consultant
January 2005

By reducing errors in demand, software developers can improve their project results and deliver high-quality software on time and on budget. This White Paper provides ample justification for investment in the management and communication aspects of the demand evaluation process.

Summary
There is strong evidence to show that developers can improve project results and target us --Deliver high-quality software by time and budget-- Demand management is the most effective way to help. This article provides some practical evidence that investment in effective demand management can generate actual returns.

Software crisis continues
In the June 1996 Fortune magazine entitled: "The trouble with software is... it sucks" 1ArticleIn his comment, industry critic Stewart Alsop accused our industry of being in a state of low software quality and reliability. When most people in the industry are angry, 2 in a report recently provided by Standish Group, a well-known market research institute, gives even a clearer view. According to the Standish Group survey (more than 352 software projects reported by more than 8,000 companies), the following conclusions are drawn:

• 31% of software projects are canceled before they are completed ($81 billion waste ).
• 53% of the project cost 189% of the budget.
• 9% of projects are completed by time and budget (large companies ).
• 16% of projects are completed by time and budget (small companies ).

To help you better understand the problem, the Standish Group survey also asked the respondents why the project failed. According to their answers, the reasons for the failure of the first three projects are listed in table 1:

Damage Factors	Percentage of answers
1) Lack of user input	12.8%
2) incomplete requirements and specification Definitions	12.3%
3) Changes to requirements and specification Definitions	11.8%

Table 1:Standish Group Damage Factors

As can be seen from the table, failure to work with users more effectively to better understand their needs, coupled with the lack of engineering training in management needs, is the main cause of software failure.

High cost due to incorrect requirements
The research completed at GTE, TRW, and IBM has measured and allocated three costs for identifying errors at different stages of the project lifecycle. These statistics are further validated by future studies 4. Although these studies are conducted independently, they all come to the same conclusion:CodeThe cost for detecting and fixing an error in the phase is one unit, so the cost for discovering and correcting an error in the demand phase is only 1/5 to 1/10. In the maintenance solution stage, the cost for discovering and correcting an error is 20 units. Figure 1 shows the main results.

The reason for this big gap is that many errors cannot be detected before the product is completed. Delayed error discovery means that the cost of fixing the error includes the cost of directly fixing the error and the cost of a series of inputs caused by fixing the error. These investments include re-designing code, re-writing documents, re-working the software, or re-replacing the Software deployed.

Requirement errors and the most common errors
Research shows that fixing errors at the demand stage is extremely expensive. If such errors do not occur frequently, the total cost of the project will be less. However, in complex software projects, demand errors are indeed the most common types of errors found. In Sheldon's research on the U.S. Air Force program 5, errors were classified by source. This study found that demand errors accounted for 41% of total errors, and logical design errors only accounted for 28% of total errors. Other studies also support this result. For example, tavolato and vincena reference the report of Tom DeMarco, indicating that 56% of all bugs can be attributed to Error 6 in the demand phase.

Demand error and rework cost
Raytheon, Dion reports that the cost of rework accounts for about 40% of the total project budget. Boehm reported that rework costs for large software projects accounted for about 50%. Due to the large number of request errors,The cost of discovering and correcting request errors accounts for 70%-85% of the total rework cost of the project.

Reduce requirement errors
There is no silver bullet that can keep you away from wrong demands. However, some organizations have provided the following technologies that can effectively reduce incorrect requirements:

• Export more efficiently
• Review requirements with customers and end users
• Better organization and documentation requirements
• Available demand warehouse to facilitate team communication
• Improve reporting process
• Better requirement-based testing and requirement Traceability

To be proficient in these activities, necessary investments in tools and training for key project members are required.

estimate the costs of Typical Projects and rework
consider an application that includes 50000 lines of code Program , its developers include six developers, one project manager, two testers, and one quality assurance engineer. To confirm the project time, the encoding is assumed to be a key path. The total project time is 24 months, based on the productivity of 350 lines of code debugged per month. If each person (developer/test/Quality Assurance) has a monthly cost of $10,000, the total project budget can be calculated to be approximately $2.4 million. For this budget, even if only 30% of the rework workload is involved, the total rework cost is about $720,000. If 70% of the rework is due to a requirement error, the total rework cost for the entire request error will exceed $0.5 million!

	Typical Project	Your project
Code line	50,000
Number of developers	6
Monthly code line per person	142.9
Time to market	24 calendar month
Monthly project member fee	$10,000
Total project work cost	$2,400,000
Total rework costs (30%)	$720,000
Rework costs due to all request errors (> 70%)	$504,000

Table 2:Project Cost Estimation for a software project

Your investment
What should we do for rework of projects with no value? It is easy to reduce requirement errors. The technologies described above can effectively reduce request errors. However, investment in tools and training is necessary for success in any process. We assume that the organization purchased the requisite's requisitepro toolkit and trained the project members on demand management concepts and tool usage. The training for these needs costs about $19,900 [10 persons * ($995 tools + $995 training)]. Are these investments worthwhile?

Bottom Line
No one can accurately predict how effectively your organization can reduce demand errors. However, it is reasonable to assume that organizations with different maturity levels can reduce requirements by 20% or more. Any such reduction can effectively affect the bottom line of the project listed in table 3 due to the amplification of the impact.

	Example 1	Example 2	Example 3	Your project
Percentage of request errors reduced	10%	20%	40%
Cost savings for Typical Projects	$50,400	$100,800	$201,600
Number of months saved in time to market	1.0	1.7	2.5
Payback Period (months)	9.5	4.7	2.4
First ProjectROI within the lifecycle	153%	407%	913%

Table 3:ROI for more effective demand management

Summary
As shown in table 3 above, even in the first project, investment in demand management tools and training can actually return. Since then, the ability of the project team to reduce wrong demands will continue to get more returns in future projects.

However, these hard fees do not include the intangible fees related to wrong requirements.. Intangible fees include the lack of deliverables that make the project resources unable to focus on rework, the loss of confidence in some users, and the loss of market opportunities, revenue and profits.

Start working. These fees clearly show that a company cannot ignore the benefits of demand management!

References

1.	Alsop. S, "The trouble with software is... it sucks", Fortune magazine, June 10,199 6
2.	The Standish Group, chaos Report, 1994
3.	Davis, A., "software requirements-objects, functions and States", Prentice Hall, 1993
4.	Boehm, B. and papaccio, C. "Understanding and controlling software costs", IEEE Transactions of software engineering, Oct 1988
5.	Sheldon, F. et al, "reliability measurement from theory to practice", IEEE software, July 1992
6.	Tavolato, P ., and K. vincena. "A prototyping methodology and its tool. "in approaches to prototyping, r budde et al ., eds ., berlin: Springer-Verlag, 1984.
7.	Dion, R. "process improvement and the specified ate balance sheet," IEEE software, (July 1993), pp. 28-35
8.	Grady, R. "practical software metrics for project management and process improvement", Prentice-Hall, Inc. 1992

References

• For more information, see the original article on the developerworks global site.
  

about the author Dean leffingwell is senior vice president of rational process and project management, he is mainly responsible for methodology, Rational Unified Process, user education and training, products and project management training for company needs and change management. He is the principal author of managing software requirements, a uniied approach (Addison Wesley Longman, 1999) and holds a master's degree in engineering from Colorado University.