Value-Based Software Engineering: Reinventing “Earned Value” Monitoring and Control Barry Boehm, LiGuo Huang University of Southern California boehm, [email protected] Abstract The Value-Based Software Engineering (VBSE) agenda described in the preceding article has the objectives of integrating value con-siderations into current and emerging software engineering princi-ples and practices, and of developing an overall framework in which they compatibly reinforce each other. In this paper, we provide a case study illustrating some of the key VBSE practices, and focusing on a particular anomaly in the monitoring and con-trol area: the “Earned Value Management System”. This is a most useful technique for monitoring and controlling the cost, schedule, and progress of a complex project. But it has absolutely nothing to say about the stakeholder value of the system being devel-oped. The paper introduces an example order-processing soft-ware project, and shows how the use of Benefits Realization Analysis, stakeholder value proposition elicitation and reconcilia-tion, and business case analysis provides a framework for stake-holder-earned-value monitoring and control. Keywords: value, risk, software economics, software life cycle, software management, requirements, architecting, software met-rics, earned value, business case analysis, monitoring and control, stakeholder win-win 1. Introduction The Value-Based Software Engineering (VBSE) agenda de-scribed in [6] has the objectives of integrating value considera-tions into current and emerging software engineering principles and practices, and of developing an overall framework in which they compatibly reinforce each other. One of these areas is value-based planning and control, in-cluding principles and practices for extending traditional cost, schedule, and product planning and control techniques to include planning and control of the value delivered to stakeholders. Current approaches for software planning and control, such as those in the Software Capability Maturity Model [19] focus on the monitoring and control of the project’s planned commitments, efforts, costs, schedules, technical activities, risks, product sizes, and critical computer resources. They do not address the monitor-ing and control of the reasons for which the project was estab-lished, or of the actual value likely to be realized by the project’s results. Recent updates such as the Capability Maturity Model-Integrated (CMMI) [1, 20] make some progress toward value-based project definition and planning. But their project monitor-ing and control processes remain focused largely on monitoring project progress with respect to execution plans. Neglecting to monitor and control with respect to the value added by software was not too risky when business values changed slowly and software was a minor contributor to business values. However, such neglect is increasingly risky in today’s (and tomorrow’s) world of software-driven product lines and tor-nado-driven [18] changes in the information technology market-place. Many projects have faithfully delivered products on or near their planned budgets and schedules, only to find out that the busi-ness need for the product has largely disappeared, or that competi-tors have already captured its planned market niche. A particular anomaly in the monitoring and control area is the “Earned Value Management System” [2]. It is a most useful tech-nique for monitoring and controlling the process of a complex project. But it has absolutely nothing to say about the stakeholder value of the system being developed. It serves a purpose, but needs to be incorporated into feedback control systems which fo-cus on the real stakeholder value being earned. In section 2, we summarize how current earned value systems are used for feedback control of software development. In sec-tions 3 and 4, we provide an alternative approach for project feed-back control which focuses on the actual stakeholder value likely to be earned by completing the project. Section 3 provides a framework for monitoring and controlling for value in terms of the DMR Benefits Realization Approach and on business case analy-sis, using an order processing system as an example. Section 4 elaborates on the value-based feedback control mechanisms and illustrates them via the example. Section 5 presents the conclu-sions and promising directions for future research and develop-ment. 2. Using “Earned Value” for Feedback Control of Software Development Performing feedback control of large software projects be-comes very difficult, because there will be hundreds of tasks going on concurrently. Some tasks will be ahead on budget and sched-ule; others will be behind. Current “earned value” [12] systems enable large-project managers to achieve better visibility and con-trol of such complex situations. Most software cost and schedule estimation models include breakdowns of a project’s budget and schedule by software com-ponent, development phase, and task activity. This enables a pro-ject to set up an Earned Value system in which the estimated cost for each task can be considered as the value earned for the project when the task is completed. The Earned Value System works as follows: 1. The project develops a set of tasks necessary for completion, and associated budgets and schedules for each. 2. Each task is assigned an earned value (EV) for its completion, usually its task budget. ACM SIGSOFT Software Engineering Notes vol 28 no 2 March 2003 Page 13. As a project proceeds, three primary quantities are reviewed at selected times T: a. The Budgeted Cost of Work Scheduled (BCWS): the sum of the EV’s of all tasks scheduled to be com-pleted by time T. b. The Budgeted Cost of Work Performed (BCWP), or project level earned value: the sum of the EV’s of all tasks actually completed by time T. c. The actual cost of the project through time T. 4. If the BCWP (budgeted cost of work performed) is equal to or greater than the BCWS (budgeted cost of work scheduled), then the project is on or ahead of schedule. 5. If the BCWP is equal to or greater than the project cost, then the project is on or ahead of budget. 6. If the BCWP is significantly less than the BCWS and/or the project cost at the time T, then the project is significantly overrunning its