November 26, 2008
URL:http://www.drdobbs.com/architecture-and-design/dr-dobbs-agile-update-1108/212200803

In This Issue:

• Strategies for Funding Software Development Projects
• Book Review: Beyond Budgeting
• Hot Links

Strategies for Funding Software Development Projects

As a result of my recent column Is Fixed Price IT Unethical?, I've been subjected to a slew of accusations about not dealing with the real world. Sigh. The issue that people have with my position on fixed-price projects is that although they would love to abandon the practice they're not able to because of the realities of their organization. They've effectively given up trying to align their organization's business policies with their IT values, one of the practices of Lean Development Governance, and can't contemplate adopting more effective strategies for funding software development projects. I, on the other hand, haven't given up. I've found that when you choose to fight for it that you can convince your business stakeholders to rethink the way that they approach project funding. I can't always change their minds, but I've been successful with a large enough percentage that I believe it's worth our while to try -- hence my original column, the goal of which is to provide people with the data that they need to reasonably argue against fixed-price funding.

An important first step is to educate business stakeholders in the various funding options that they have available to them, or depending on the situation to understand the implications of the funding strategy which they're currently following. In this update I overview nine strategies for funding software development projects, discussing the tradeoffs of each. The first five strategies are very unfortunate at best and unethical at worst. The last four strategies require a good partnership between the business and IT, flexibility on the part of management, discipline on the part of IT, and the willingness of the business to be accountable for the decisions that it makes. These requirements can be difficult for many organizations to meet, hence the hopelessness felt by many IT professionals.

The first five strategies are different flavors of "fixed price, schedule, and scope" strategies which I'll refer to as fixed price for the sake of simplicity. These strategies are typically born from a lack of trust between the business and their IT provider, poor relationships between the two, and a desire for the business to not consider their IT provider to be an equal partner. Needless to say, these factors all bode ill for the long-term success of your IT department, let alone a single project.

Fixed-price strategies are motivated by the demand of business stakeholders for an "accurate", up-front estimate, the goal being to reduce the overall financial risk to the business. The five fixed-price strategies, which can be combined, are:

• Strategy #1: Fixed-Price with Intended Descoping. With this approach some of the functionality that was originally promised at the beginning of the project will be dropped later in the project when it becomes obvious that there is insufficient funding. The benefit is that on the surface IT can still claim that they came in on budget, something that is clearly not true once you consider the costs that have been pushed to a future release. When it happens rarely there is nothing wrong with this strategy, but when it's commonplace for the IT provider to "surprisingly" discover the need to descope then we need to question their ethics.
• Strategy #2: Fixed-Price with Intended Extension. As the project gets near the end of the budget the IT Provider "realizes" that they've misestimated and asks the customer for more money. This situation can honestly occur in practice, but is arguably extortion if the customer isn't given any other choice. It is also unethical if the IT provider presented themselves as experienced enough to complete the project, and hence claimed that their estimate was accurate when it clearly had little hope of being so.
• Strategy #3: Fixed-Price with Intended Change Prevention With this strategy the IT provider will pad the budget as much as they can to protect themselves and then make it as difficult as possible for the business to change their requirements without paying them. Although this increases the chance that the IT provider will deliver on time and on budget, it pretty much ensures that much of the functionality delivered doesn't meet the real needs of the business (although the system does fulfill the specification). In this case I would question the ethics of charging the business for functionality that they don't actually want.
• Strategy #4: Fixed-Price with Intended Legal Battle. This is an approach that is sometimes taken by IT providers which are external to the actual business customer. With this strategy the IT provider puts in a purposely low estimate to win the work but later reneges on their promise to deliver the system for the agreed price. They're willing to fight it out in court with the customer, knowing full well that most customers will simply give up once they realize how long and expensive it is to do so. The IT provider may choose to "share the pain" but returning some of their pay after some legal negotiations. The only clear winners with this approach are the lawyers.
• Strategy #5: Fixed-Price Defined by Business. With this approach the business insists on setting the price of the contract and the IT provider often accepts an estimate that they know won't work. This can occur with external IT providers who are desperate for the business and with internal IT providers who hope that everything will work out despite the odds. In productive environments the business should be responsible for prioritizing the requirements and the IT provider is responsible for providing viable estimates. When either party crosses this line, as the business has in this case, the project is often put at risk.

My experience is that we can do a lot better than the five previously described fixed-price strategies. IT departments with a good relationship with their business stakeholders, one that is built on trust and respect, will adopt one of the following project funding strategies:

• Strategy #6: Fixed-Price with Variable Scope. With this approach you set the price and then deliver the functionality which provides the highest return on investment (ROI) as defined by your stakeholders. To accomplish this requirements are treated like a prioritized stack and you work down that stack in priority order. If stakeholders want to change a requirement, or add a new one, without changing the price then they need to drop a requirement of equal or greater value from the scope of the project. The scope varies with this approach, which is often a good thing considering the difficulty of defining requirements up front, and you get the best value for your IT investment.
• Strategy #7. Staged-Gate Funding. With this strategy the project is funded a period at a time. This doesn't imply that you need to take a waterfall approach to development, for example the Unified Process has a risk-driven lifecycle where in each phase you address a specific category at risk, and then at the end of that phase you decide whether it makes sense to continue with the project and to what extent. The project funding is effect provided in a phased manner only if the project appears to be still on a path to success. This strategy is very popular in organizations that are transitioning from fixed-price funding approaches to time-and-material (T&M) approaches.
• Strategy #8: Low Time-and-Material Rate with Delivery Bonuses. This strategy is common when external, agile IT providers are involved. The basic idea is that the IT provider is paid a low T&M rate which covers their costs but receives bonuses throughout the project based on pre-defined criteria, such as delivery of working software each iteration, thereby providing them with opportunity to make a profit. This approach effectively shares the financial risk between the IT provider and the customer.
• Strategy #9: Time-and-Material Funding. With this strategy the IT provider is paid a specific rate for their efforts and paid for their incurred costs. This works incredibly well for smaller, simpler projects or when there is a significant level of trust built up between IT and the business.

As you've seen, there are many approaches to funding software development projects, and contrary to popular belief in many organizations, not all of them involve a fixed price. Business has to ask for options when it comes to funding strategies for IT because in most cases the IT provider will simply do what they're told and follow the strategy being set out by the business. Sadly many IT professionals, in particular those working in large organizations or for system integrators, have all but given up on trying to convince the business to adopt one of these strategies. As professionals it behooves us to give our business stakeholders a choice in the way that they fund projects. If we choose to fight for what we know works we'll eventually work our way off of the fixed-price treadmill that we currently find ourselves on.

Book Review

Beyond Budgeting: How Managers Can Break Free of the Annual Performance Trap
Jeremy Hope and Robin Fraser
Harvard Business School Press, 2003

I've been waiting a long time to find the right time to review Jeremy Hope and Robin Fraser's Beyond Budgeting: How Managers Can Break Free of the Annual Performance Trap, and this is clearly it. In Beyond Budgeting Hope and Fraser review the challenges with existing annual budgeting processes, and provide proven strategies for effectively addressing the business risks that traditional budgeting futilely strives to address. The problem with traditional budgeting is that managers soon begin to focus on making their numbers instead of adding real value to your customers. You know your organization has this problem if people commonly lament that management is too focused on quarterly results instead of long-term investment -- clearly a touchy subject in today's economic climate.

The philosophies described in the book are very similar to those espoused by the agile community --pushing decision-making authority down the hierarchy, promoting flexibility and quick decision making, promoting open and honest decision making, and promoting accountability and responsibility on the part of individuals. There are numerous examples, both good and bad, from a range of organizations world-wide, including large banks, petrochemical companies, manufacturing companies, and wholesalers. If you're truly interested in changing the business culture within your organization, this book will be a critical resource for you.

Hot Links

Is Fixed-Price Software Development Unethical?

The IBM Whitepaper Lean Development Governance by myself and Per Kroll overviews a collection of practice for effective governance of development projects.

My July 2008 Agile Update, Reducing the Risk of Fixed-Price Projects describes five strategies for reducing the inherent risks associated with fixed price projects. If you can't avoid fixed price then at least be smart about how you go about them.

My September 2007 column Agile on a Fixed Budget describes strategies for running agile projects for all combinations of fixing, or not fixing, the schedule, scope, and budget.

The Change Prevention Anti-Patternis described here.

Counteracting the False Arguments for Big Modeling Up Front (BMUF) describes the risks associated with detailed modeling early in a software development project.

Architecture Envisioning: An Agile Best Practice describes how to go about initial architecture modeling on an agile project in a streamlined manner.

Requirements Envisioning: An Agile Best Practice describes how to go about initial requirements modeling on an agile project in a streamlined manner.

I've summarized a collection of Agile project planning tips at www.ambysoft.com/essays/agileProjectPlanning.html

Iteration Negative One describes the portfolio management efforts which occur before the "start" of a software development project to select the right projects and get initial funding for them.

My Agility@Scale blog is posted at www.ibm.com/developerworks/blogs/page/ambler where I discuss strategies for adopting and applying agile strategies in complex environments.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.