Humans and Technology Technical Report, HaT TR 2006.01, Sept 4, 2006
Abstract
I’ve been collecting ideas people have for contracts on agile projects.
Fixed-price, fixed-scope (and possibly fixed-time)
- This option is the old one: Do your best, however you do it, to come up with a number for the project. Once inside the project, squeeze all the fat out of the process, using all the best agile techniques you can muster (see Process: the 4th dimension) to deliver it as well as you can. As far as I can tell, agile techniques do not change your ability to estimate a project. Despite our most fervent wishes, estimating a project is still a matter of previous experience, feel, and guesswork. Fixed-everything projects make sense when the requirements are very stable. They are also used when the two parties don’t trust each other, even though there is usually plenty of leeway for one party to twist the situation to the other’s disadvantage if they want.
Fixed-price, fixed-scope (and possibly fixed-time) but collaborate with the customers to alter scope anyway
- A risky approach, I have seen it done successfully several times, twice for commercial projects and once for a state government project. Jeff Patton (discussion: Re: Jeff Patton) describes working closely with the customers at the start of the project to identify needs, wishes and priorities. As the project proceeded, Jeff made sure they were always working on the most important items. As –they got close to the end of the time period and it was clear they would come up short on features, he made sure that the items left undone were clearly the least important ones. Those the customer either forgave or rolled into a follow-on contract.
- The government contract I tracked was again a fixed-everything contract. The team worked closely with the users of the system, delivering and installing running, tested, usable software every month. After each delivery, they discussed with the users whether to continue with the contract as written, or change directions based on what the users really needed. I found it remarkably brave of the contracted company to follow the users’ requests in deviation, because in a hostile sponsorship situation, they would have been at risk of non-payment. However, the user base was so happy with the usefulness of the functionality delivered that the contracted company got paid in full. This was a case of converting a fixed-price, fixed-scope, fixed-time contract into a time-and-materials contract on the fly. A dangerous but wonderful strategy if you can accomplish it. (see Benefits of the fix-and-switch contract (discussion: Re: Benefits of the fix-and-switch contract).)
Time and materials
- This is simply a matter of paying for work as it gets done. It is obviously the best format to use if the requirements are volatile. In one case – I won’t even call it a project – the sponsor changed the requirements wildly, even up to days before delivery. The contracted company always delivered whatever they had running at the end of the quarter, and the sponsor always had complete control as to what was on the top of the priority list. Over a period of years, it became simply a balanced flow of useful software in one direction and money in the other direction..
- If the sponsor trusts the contracted company, this is the simplest contract to use. The difficulty is that it requires a certain level trust. What some contractors do is to request a trial period. Using the agile approach, they deliver usable functionality early, and so establish the trust of the sponsor for subsequent work
Not-to-exceed with fixed-fee (NTE/FF)
- This is the contract method used in the airport construction example on page 97???. It presupposed stable requirements. “Fixed fee” means that the contracted company is guaranteed a certain profit margin over their materials and subcontractors’ fees. This protects the contracted company in case requirements are reduced or the work goes faster than estimated. “Not to exceed” puts a ceiling on the total amount paid to the contracted company, which protects the sponsor in case the work goes slower than expected. With protection for both sides, both sponsors and contracted company can look for ways to speed the work, and live with unfortunate events. The airport construction project used this form with Payment on incremental acceptance.
Fixed price per function point or story point
- When the customer and contracted company can agree on a unit of delivery, such as function points or story points, then they can settle on a price for each unit delivered. A number of contract houses these days estimate the size of a project in function points, create a price per function point delivered, and then have an certified function point auditor assess the actual number of function points delivered in the end. The customer then pays that amount, not the originally estimated amount. This is a nice contract form, because it encourages the contracted company to work more efficiently (to increase their pay per delivered function point) and it allows the customer to change the requirements along the way.
- The same can be done with XP-style story points, except that there aren’t any certified story point examiners to judge the final result.
Bob Martin’s idea
- Bob Martin of Object Mentor posted an interesting variant to get around this problem: a base fee per story point, plus a lower-than-usual (close-to or below cost) fee per hour. This biases the contracted company’s to deliver early, but gives them some protection in case work proceeds slower than expected. Bob Martin described it this way:
- ”[A]gree to pay a certain amount for each point completed, plus a certain amount for each hour worked. For example, let’s say you’ve got a project of 1000 points. Let’s also say that a team of four has established an estimated velocity of 50 points per week. This looks like about an 80 man-week job. At $100/hour this would be a $320,000 job. So lets reduce the hourly rate to $30/hour, and ask the customer for $224 per point.
- This sets up a very interesting dynamic. If the job really does take 80 man-weeks, then it will cost the same. If it takes 100 man-weeks then it will cost $344,000. If it takes 70 man-weeks it will cost $308,000. Notice that this is a small difference for a significant amount of time. Notice also that you, as developer feel strong motivation to be done early, since that increases your true hourly rate.”
- I have not seen that model in action myself, but several people have written in recommending it.
Venture-capital financing model
- This can be used with any of the above contract forms. In this model, the sponsor gives a round of financing for a certain amount of work, and the contracted company must produce results in order to get more funding. The sponsor can cut their losses at any time if they are not getting the results they need. They can presumably alter the terms of the contract after each work period. The result of a work period need not be working software; it could be a paper study, or a requirements document, or anything the sponsor selects.
- The venture-capital finance model works well with agile providers, since the agile provider is used to delivering useful, working software early and regularly.
- I find it an odd irony that the venture capital financiers running start-ups that I have encountered don’t take advantage of their own model to the extent agile teams do. The venture financiers let the evaluation markers occur too far apart in time. If they attached funding to monthly releases, that would oblige the start-up team to think through what it really can accomplish each month. The monthly progress would give the financiers a better sense of the start-up company’s real progress.
Incremental delivery with payment on incremental acceptance
- This can be used with either fixed-everything contracts or the NTE/FF contract. The sponsor expects incremental delivery of integrated, tested systems, constructs and runs acceptance tests at each delivery increment, and pays the contracted company after each successful incremental acceptance. This was used in the airport construction project and in Solystic’s French Post Office contract. Both project leaders told me that this payment schedule has a wonderful motivating effect on the contracted company. The requirement, of course, is that the sponsors have an understanding of incremental development and can make acceptance tests for the incremental deliveries.
Jonathan House’s idea
- Fixed-price, but with a 5% bonus if they deliver on time, or fixed price and time, but with a 5% reduction if they don’t deliver on time.
Time and materials variant
- Fixed range of allowed billing hours (e.g. 180-240 per month for a whole team) to put bounds on spending. Some way to extend hours for more money, get money back if can’t do all hours.
IDIQ: Indefinite Delivery, Indefinite Quantity
- This is a topic unto itself. See Indefinite Delivery, Indefinite Quantity or IDIQ contracts (discussion: Re: Indefinite Delivery, Indefinite Quantity or IDIQ contracts)
Norwegian PS 2000 Standard contract
- http://dataforeningen.no/?module=Articles;action=ArticleFolder.publicOpenFolder;ID=1044 “The main feature of the contract for software development is that it provides mechanisms for establishing a common understanding between customer and the developer and a flexible iterative model for development suited for an environment of uncertainties and risks.” ...”
- Stage by stage, iterative development model securing ability to benefit from increasing understanding of the requirements and challenges
- Close co-operation between supplier and customer
- Incentives and sanctions in combination with target pricing
- Procedures for conflict resolution with an expert as a mediator ”
- You need to order it (it costs several thousand Norwegian kronor):
Missing in Action: Partial Delivery with Mandatory Requirements Changes
- What I’m dearly missing from this list is one where the supplier is obliged to deliver something part-way through the contract and then re-gather requirements based upon what’s been learned up through early usage. We really need this for government-office IT software (most urgently – everyone probably needs it). Help?
Target-Cost contract
- From http://www.sparkboxx.com/sparkboxx/types-of-contracts.html: “In a TC contract an initial target of functionality is set. Based on exploratory meetings a target is set for the amount of resources and time needed to implement the initial specifications. Based on the target functionality an initial cost price is set, increased by a contingency buffer and a profit margin. ... When the customer increases the scope during the project or when new requirements pop-up during the development phase the additions can be grouped into three groups (Horowitz 2005): fixes, clarifications and enhancements.” Read more.
- The original article on Target Cost is at http://cyrusinnovation.com/downloads/agile2005_cyrusinnovation_targetcostcontracts_paper.pdf
Other articles about agile contract
Nice round up.
Payment per story points seems the best to me.
I like the idea of paying 5% if delivered on time. That could be a bonus split for the team.
Thanks for sharing!
-by MarcoBarbosa on 4/29/2010 at 5:33 PM
I am still partial to #1. I do not believe in charging for time, only results. Billing by the hour is inherently unethical.
-by Mark Richman on 4/30/2010 at 9:43 AM
@Mark — charging for time is not unethical, it’s just a kind of agreement. It’s appropriate when the customer can’t or won’t define precisely what they want in advance.
-by xpmatteo on 6/24/2010 at 10:53 AM
I read somewhere that we should have a higher price per story point in early sprints and a lower one in late sprints (since the idea of Agile is to deliver the most value early). Does anyone have some experience with this ? Do you know about any formula to put this in place ?
Regards,
Chris
-by Chris on 7/7/2010 at 6:27 AM
Good question, Chris … I have an idea, just for fun – how about reversing that logic and charge less for early sprints and more for later sprints, to entice customers to get their value quicker, up front, and to quit the product development sooner, as the value/feature starts to drop off? Encourage the behavior we want to see?
Any thought? :)
-by Alistair on 7/7/2010 at 11:10 AM
I am battling with one central problem in agile: how do you remain “agile” and open to change when you’re working against a fixed budget and defined scope, and a customer who is not a “software person”.
We use an adapted version of SCRUM for web development, which is part-software and part-design. Our customers have only a limited interest in being involved in the project. They want x by x date. But they also want to make changes along the way.
So do you baseline the project against the original scope document? And then measure each change impact on the budget?
It’s driving me kind of nuts — how can you merge an agile process with a non-agile budget?
-by Jarred Cinman on 11/25/2009 at 1:38 PM
I think
Earned-value and burn charts (discussion: Re: Earned-value and burn charts) and
http://en.wikipedia.org/wiki/Project_triangle might help you.
Also: don’t be afraid to say “no” to the customer. Every time you say “yes” to the customer you lose a bit of control over the project. If you say “yes” too much the project will spin out of control.
-by Floyd on 11/26/2009 at 7:18 AM
Thanks, could be a nice data for my benchmarking in the subject of CM.
LSS Expert – IECOACHdotCOM
-by Johan Wennermark on 9/21/2011 at 2:55 AM
bonuses and penalties can be a useful way to motivate the service provider but in the final analysis they really just change the arithmetic, not the approach; supplier cost and customer benefit progress/regress in a linear fashion. shift to marginal thinking, e.g., deliver early/at better quality/etc. and I will increase your marginal rate of return; deliver late/worse/etc. and I will decrease your marginal rate of return. With this model, the supplier is motivated to be more efficient, not just faster. Customer gets lower overall cost; supplier has strong motivation to deliver at or above expectation and strong motivation to avoid delivering below expectation.
-by Ken on 11/28/2011 at 3:21 PM
bonuses and penalties can be a useful way to motivate the service provider but in the final analysis they really just change the arithmetic, not the approach; supplier cost and customer benefit progress/regress in a linear fashion. shift to marginal thinking, e.g., deliver early/at better quality/etc. and I will increase your marginal rate of return; deliver late/worse/etc. and I will decrease your marginal rate of return. With this model, the supplier is motivated to be more efficient, not just faster. Customer gets lower overall cost; supplier has strong motivation to deliver at or above expectation and strong motivation to avoid delivering below expectation.
-by Ken on 11/28/2011 at 3:51 PM
I have participated in a Swedish market initiative to establish general terms for agile projects. I have in this work introduced a new term called “Spare timeboxes” (or spare Sprints). The purpose of these are to allow limiited scope creep. Number of spare timeboxes needed in a project depends on the uncertainty of requirements.
It’s also possible to agree incentives models based on use of spare timboxes.
A preplanning would require a definied timebox sequence, also including thes spare timeboxes. Based on this sequennce and assumed resource utilization it’s poosible the agree a goal price.
-by Lars Wendestam on 2/6/2012 at 8:52 AM