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

The Agile Edge Fixed price refers to a project where the cost, schedule, and scope are set early in the lifecycle when the composition of your teams change, when the pool of people from which you draw from change, and when the skillsets of your people change (hopefully for the better). Part of the foundation on which your estimate is based is constantly shifting, reducing your ability to be precise. • Up-front estimation motivates Big Requirements Up Front (BRUF), which in turn results in significant waste. To reduce the risk of uncertainty in your estimates, you need to increase the level of information that goes into those estimates. This motivates you to do detailed modeling of your requirements and potentially even your architecture. This unfortunately ignores the facts that people aren’t very good at defining up front what they want and even if they were, the requirements will evolve anyway. The implication is that the sizing measures that are input into your estimate are also on shifting ground. The “Chaos Report” shows that projects that took a BRUF approach ended up delivering systems (when they delivered anything at all) where 45 percent of the functionality was never used by stakeholders. So, by insisting on a fixed-price strategy, often to minimize financial risk, customers ensure that on average close to half of their development budget is wasted. (I’ve written a detailed article about this phenomena; see www.agilemodeling .com/essays/examiningBRUF.htm.) Yes, up-front estimating may motivate IT providers to create detailed plans, but apparently they aren’t very good in practice. • Being held to an initial estimate motives IT providers to adopt strict change management, which in turn prevents the customer from getting what they actually want. The only real option to protect yourself from the risks of fixed-price IT projects is to adopt a traditional change management strategy where you make it difficult for the customer to modify their 52 Dr. Dobb’s Journal l www.ddj.com l August 2008 requirements. These processes are usually onerous, make potential schedule slippage explicit (a good thing), and typically make the customer pay handsomely for any changes. These factors reduce customer motivation to change their defined requirements, even though their requirements have in fact changed, effectively turning the change management strategy into a change prevention strategy. Not only do traditional change prevention strategies exacerbate the challenges associated with BRUF, they are ethically questionable because you’re effectively motivating customers to pay for functionality they really don’t want. You still need a strategy for change management, but it doesn’t need to be the bastardized processes that we see in the traditional world. Agile change management strategies treat requirements like a prioritized stack that is managed by the stakeholders, and the development team merely pulls work from the top of the stack each iteration, thereby producing the greatest ROI as defined by the stakeholders. This lets stakeholders manage the scope, thereby getting software that actually meets their needs with the trade-off that they are now accountable for these scope changes. • You waste time and effort on overly precise up-front estimating. We need to question whether the investment being made in up-front estimating to increase its precision is worth it. It’s likely a good investment of $10,000 to determine that your project will likely come in between $2.3 and $3.5 million, but it likely isn’t worth an additional $100,000 to determine that it will be between $2.85 and $3.1 million. Customers often don’t realize the amount of effort required to obtain just a bit more precision in our estimates. Is Fixed-Price IT Ethical? There are some very clear and obvious challenges with fixed-price IT projects. I believe that this is the direct result of the inherent nature of IT projects. Traditionally we’ve wanted to believe in the concept that “software engineering” is 80 percent science and 20 percent art, but in practice development has proven to be closer to 20 percent science and 80 percent art. Or perhaps the 20 percent of software engineering that is art is simply 16 times harder than the 80 percent that is science. Regardless, after four decades of struggling with fixed-price IT projects, building a buffer into your estimate is merely a band-aid that reduces some of your risk. It’s time that we start questioning the ethics of approach. For a fixed-price IT project to be considered ethical, three criteria must be met. First, the customer must explicitly insist on a fixed-price approach. Second, the customer has been educated as to the inherent risks associated with fixed-price IT projects (feel free to give them a copy of this column). Third, the customer has been given other choices, such as staged-gate funding common on large projects or continuous-flow funding common with agile projects, has had the trade-offs explained to them, and has still explicitly chosen a fixed-price approach. As professionals, we must actively question the ethics of what we do, even when we’ve been doing these things for decades. We know that we have significant challenges around formal approaches to estimation and to traditional project management in general. Too many IT professionals give up when faced with customer demands for fixed-price IT projects, thereby choosing to work in a manner that dramatically increases project risk. We have to stop accepting the status quo and push back against our customers and help them to rethink this strategy. We fundamentally know that fixedprice IT projects are a very poor way of working. Luckily, so do our customers. Whenever a customer insists on a fixedpriced IT project, even within the scope of an RFP that’s been put out to bid, ethically we must attempt to dissuade them from this perilous path. Unless we start providing a consistent front against fixed-price projects, we will never get off this treadmill that we find ourselves on. We must actively choose to reduce the inherent risks in our industry, and the desire by customers for fixed-price IT projects is likely the greatest one that we face. DDJ Scott is Practice Leader Agile Development for IBM Rational. http://www.agilemodeling.com/essays/examiningBRUF.htm http://www.agilemodeling.com/essays/examiningBRUF.htm 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.