DISCUSSIÓ DELS RESULTATS

Your funding strategy, although not the level of funding, will likely be set for you long before your project even begins. For example, most organizations have policies regarding how projects are funded, often regardless of the paradigm followed. There are three basic strategies, compared in Table 6.4, for funding agile projects:

• “Fixed price.” At the beginning of the project you should develop, and then commit to, an initial estimate that is based on your up-front requirements and architecture modeling efforts. Hopefully this estimate is given as a range, as studies have shown that up-front estimating techniques such as COCOMO II or function points are accurate within +/-30% most of the time. However the July 2009 State of the IT Union survey found that on average organizations are aiming for +/- 11% (their actual results come in at +/- 19% on average, but only after doing things such as dropping scope, changing the estimated cost, or changing the delivery date).

• Stage gate. With this strategy you estimate and then fund the project for a given period of time before going back for more funding. For example, you may be allocated suffi-cient money to fund the project for a three-month period at which point you must evalu-ate the viability of the project to receive further funding. Note that stages don’t have to be based on specific time periods; they could instead be based on goals such as the DAD milestones of reaching stakeholder consensus, proving the architecture with working code, or building a portion of the system.

• Time and materials (T&M). With this approach you pay as you go, requiring your management team to actually govern the project effectively. Many organizations believe a T&M strategy to be risky, which it often is when your IT governance strategy isn’t very effective. An interesting variation, particularly in a situation where a service provider is doing the development, is an approach where a low rate is paid for their time, which covers their basic costs, the cost of materials is paid out directly, and delivery bonuses are paid for working software. This spreads the risk between the customer/

stakeholder and the service provider. The service provider has their costs covered but won’t make a profit unless they consistently deliver quality software.

126 Chapter 6 The Inception Phase

ptg8106388 Table 6.4 Comparing Project Funding Strategies

Strategy Potential Advantages Potential Disadvantages Considerations

Securing Funding127 uncertainty faced by the project team.

Sets false expectations about accuracy and your ability to plan.

When scope and schedule are also fixed it motivates questionable behav-ior on the part of IT professionals.²

Works well when the scope of what you need to deliver is allowed to vary.

Stakeholders have caught on to the fact that most IT teams are padding the budget, so will do their best to negotiate that padding away.

High probability that you will need to go back and negotiate for more fund-ing, which in turn can lower stake-holder trust in your ability to get the job done.

Fixed with range Provides stakeholders with a more realistic assessment of the uncertainty faced by the team.

Many stakeholders will focus on the lower end of the estimate range.

Many stakeholders don’t understand the need for ranged estimates (see Chapter 10 for a detailed discussion).

You will likely need to educate some of your stakeholders regarding the desirability of a ranged estimate.

Staged Lowers financial risk of project.

Provides stakeholders with financial leverage over your project.

Some organizations have an onerous project funding process, so requiring teams to obtain funding in stages can increase their bureaucratic overhead and increase risk of delivering late.

Align your funding gates with lifecycle milestones to hopefully reduce overall overhead and to focus both stakeholders and the teams on the importance of the milestone reviews.

(continued) 2. Scott has done extensive research into these behaviors, which include preventing requirements change; lying about cost, schedule, or scope; and extorting

additional funds late in the project lifecycle. Several articles are published on drdobbs.com summarizing this work.

ptg8106388 128Chapter 6The Inception Phase

Time and materials (T&M)

Significantly lower financial risk when projects are governed appropriately (see Chapter 20).

Requires stakeholders to actively monitor the project.

Some organizations have mistakenly concluded that a T&M approach is a risky way to fund IT projects.

Invariably these organizations prove to have ineffective governance strategies where stakeholders take a

“hands off” approach to IT.

Table 6.4 Comparing Project Funding Strategies (continued)

Strategy Potential Advantages Potential Disadvantages Considerations

T&M with performance bonus

Low financial risk for both the project team and for stakeholders.

Requires active monitoring by stake-holders and a clear definition of how to determine whether the project team has met their service level agreement (SLA) and therefore has earned their performance bonus.

Works very well for outsourced projects.

ptg8106388 The point is that there are several strategies for funding agile software development

projects, just as there are several strategies for funding traditional software development projects.

Our experience is that fixed-price funding strategies are incredibly poor practice, which greatly increases the risk of your software development projects. We recognize how hard it can be to change this desire on the part of our business stakeholders, but have also had success changing their minds. If you choose to persevere, which is a difficult decision to make, you can help your organization’s decision makers to adopt more effective strategies. Like you they want to improve the effectiveness of your IT efforts but may not understand the implications of what they ask for sometimes. We prefer a time and materials approach, although we have been successful with staged-gate strategies.

L

T

—F

P

E

I

P

R

Having been a partner of a large IT services firm, Mark can tell you that agreeing to deliver software based on a fixed priced is risky and has the potential to seriously cripple the suc-cessful bidder financially. It is common in the business to bid low to win the contract, and then make the required profit by issuing change requests when the requirements inevitably change. An alternative to this approach is for the vendor to build a huge contingency into the bid. To be frank, customers that pay for projects based on fixed-price are wasting a huge amount of money.

Mark helped move an organization from a fixed price, offshore model to a better approach.

The key was to fix the cost (budget), the schedule (with quarterly releases), but allow for variable scope. Business goals for the program and project streams were agreed to at a very high level. What this agile approach promised was that while detailed achievable scope could not be promised in advance, the budget invested would result in the best use of the funds with an optimized development process, and the highest value features being deliv-ered, on time and on budget. With a history of going over budget, missing deadlines, and solutions that failed to deliver expected results, this was a huge improvement. This large company is now in the process of adopting DAD organization wide.