Dr. Dobb's Journal - August 2008 - (Page 50)

The Agile Edge by Scott W. Ambler Is Fixed-Price Software Development Unethical? Reducing risks, better serving customers ONE OF THE RISKIEST decisions you can make in software development is to require a “precise” cost and schedule estimate at the beginning of the project. Although there is nothing wrong with fixing just the price, as I wrote in “Agile on a Fixed Budget” (www.ddj .com/architect/201202925), the situation quickly becomes dysfunctional when you also decide to fix the schedule and the project scope. Although customers often demand to work in this manner, particularly when the system is being built by another organization such as a system integrator (SI), as professionals we must question the ethics of fixed-price IT projects. We know fixed price is a bad idea, our customers inherently know fixed price is a bad idea, and it’s high time that as an industry we choose to abandon this highly questionable approach. I want to start by defining three critical terms: • Fixed price refers to a project where the cost, schedule, and scope are set early in the lifecycle. “Fixed-iron triangle project” would also be a valid term, albeit a mouthful. This is different from a “fixed-budget project” where the budget is set, but at least one (if not both) of the scope or schedule are allowed to vary. • Customer refers to the person(s) or organization(s) for which an IT solution is being developed (or purchased, as the case may be). • IT provider refers to the person(s) or organization(s) who performs the work to provide the solution to the customer. The IT provider may be internal to the customer (for example, the customer is a bank and the IT provider is the IT department within that bank) or external to it (for example, the bank chooses to hire an SI to build a system.) I also need to set the context for this discussion. First, my argument is against fixed-price projects, not fixed-budget projects. The constraints imposed by fixed-price approaches reduce the flexibility of both the customer and the IT provider and thereby increase project risk unacceptably. Second, for simplicity I assume that you work for an IT provider even though some readers are business stakeholders. • To choose projects with the highest ROI. Customers have many opportunities to invest their money, your project is just one of them, and therefore they want to choose the best available options. They assume that by requiring all project teams to produce a common set of cost and benefit estimates, it enables them to compare “apples with apples” . • To force you to prepare a viable plan. By forcing you to give an accurate estimate that you’ll be held to, you are effectively motivated to think through how you’re going to perform the work. • To choose between several IT providers. The customer wants the best deal possible so they put out a request for proposal (RFP) to several IT providers who must then bid for the work. This gives them options to choose from and motivates the IT providers to reduce their margins in the face of competition. • To support annual budgeting. IT outlays are a critical component any organization’s budget, typically 2–15 percent of the overall budget, so the customer wants to know how much money to allocate to the project in the coming year(s) for the project. • To “hide” IT costs. Politically it can be easier to admit that a project costs $500,000 to implement than the fact that they’re paying you $400 an hour to do so. • To increase their comfort level with potentially large projects. Few people are comfortable with initiating a three-year, $25 million project. Then again, without a “good” estimate, perhaps it’s really a seven-year $85 million project or a five-year $210 million project. • To conform to what IT tells them to do. For several decades traditional software engineering theory has told us to do formal, up-front cost estimates. In turn, we have taught our customers that this is the way things are done. • To conform to what the organization tells them to do. For example, many government organizations have a defined request for proposal (RFP) process that insists on a fixed-price approach. Neither you nor your customer may want to work this way, but it is incredibly difficult for them to forgo a fixed-price approach. These desires are all reasonable, at least on the surface, but unfortunately aren’t realistic in practice. The reality of IT projects doesn’t support the theory behind fixed-price approaches. Why Fixed Price? There are many reasons why customers want to take a fixed-price approach to IT projects: • To reduce financial risk. Customers believe that by getting you to agree to a set price, they are capping their potential financial outlay, effectively offloading the financial risk onto you. 50 Dr. Dobb’s Journal l www.ddj.com l August 2008 Some Inconvenient Truths Formal cost estimation strategies—COCOMO I/II, Function Points, Feature Points, and SLIM, to name a few—are based on the same fundamental strategy. First you identify the scope of the system and http://www.ddj.com/architect/201202925 http://www.ddj.com/architect/201202925 http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - August 2008

Dr. Dobb's Journal - August 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries Developer’s Notebook A Conversation with Christos Papadimitriou OpenGL and Mobile Devices: Round 2 Ellipse Specification Using Vectors Embed Custom GUIs in WPF Building RIAs on J2EE Foundations Disentangling Concepts in Object-Oriented Systems The Agile Edge Effective Concurrency Swaine’s Flames

Dr. Dobb's Journal - August 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.