Greg Young [MVP]

Sponsors

The Lounge

Syndication

Recent Posts

Tags

View more

News

Archives

Advertisement

Greg Young [MVP] » Agile: Fixed Price Bids
Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Agile: Fixed Price Bids

This post is coming up from a recent discussion I had with Rusty Zarse, these thoughts have crossed my mind before but the discussion put them back on the top of the stack in my brain. I have also been writing a lot lately about low level CLR type stuff and I don’t want to get shoehorned as a CLR nerd so I also figured it was time for a non-low level post.

I had my first agile experience way back in 1999 (well XP but close enough) I have always leaned towards agile methods in corporate environments. There is however one hurdle we must overcome before agile methodologies can gain a wider acceptance. This hurdle is not getting people to accept pair programming, recognizing that writing unit tests and refactoring does in fact lead to better code, or the acceptance of documents having prices associated with them. This idea is not a new idea but a dredging up of an old one (with a bit of a twist) that has never really had a good answer.

Agile methodologies happen to have a fairly large impedance mismatch with the legal contracts associated with a project.  Agile methodologies are all about trust, contracts are all about protection. The very concept of a contract requires heavy documentation as to what each side’s responsibilities are in order to fulfill their end of the contract. Can you imagine for a minute going to a builder in a new development around the corner from your house and signing a $300,000 contract for them build you a house without a floor plan or other specifications being included in the contract?

Not surprisingly when a project is being outsourced companies also like to know up front how much the project will cost so they can accurately detail the financial risk of the project. Since the contracting firm is forced to put forward a fixed price bid the company needs to get a detailed specification in order to put a fixed scope of work into the contract for their own protection.

The problem in dealing with agile methodologies in these situations is not when things go great with beautiful customer relations and a successful product. The issues raise their ugly heads when the project fails, since the contracting company is contracted to work on a moving target when have they legally met their obligations of the contract? The hiring company could feasibly continue to add functionality way beyond the initial scope of the project.

Martin Fowler has written a bit on this issue which suggests that you should instead be setting goals based upon money and time lines when dealing with fixed bid contracts.

To handle this with a fixed price contract you essentially come up with a plan that says "we have $x to spend and we need a release on 1 Dec. We'll collaborate together to come up with the best set of features to go live with on that date."

There can be no teeth in the contract to insure the hiring company that they will in fact receive a product that works to their specifications; the contracting company cannot in their own best interest allow such teeth to be put in since they are approaching a moving target.  Continuing with the house metaphor, can you imagine going to the building company and signing a contract saying they will work on the house for 75 days, they estimate it will take 75 days but they may be off by up to 40-50%. If they happen to not finish your house in the 75 days then you can feel free to pay them more until the house is finished unless of course the builder has someone who will pay them more in which case they will be unavailable due to scheduling conflict.  If we take a closer look at Martin’s suggestion what the hiring company has done is actually bought a block of time at a fixed price, there is no teeth in the contract stating that the software will be complete (or that the plumbing will be installed).

This can open the contracting company up to lawsuits that are nearly impossible to fight and will likely end up in arbitration. The contract says that company x will provide company y a payroll system by December 1st on a 500,000 budget. What is the exact definition of a payroll system? The functional requirements of the system have simply been collaborated on since the inception of the project. Since there are no detailed requirement documents being brought together and signed off on the hiring company could easily gain a good legal standing in a claim against the contracting company.

This issue is best shown when dealing with government based RFP’s. Can you imagine the political turmoil if a 3 million dollar system was contracted in such a way and at the end of the contract the contracting company refused to continue work because they had received a higher paying contract? A politician can, which is why it will be very hard to sell anything to them without them being able to put real teeth into the contract to protect their and their constituents’ (I guess I should have just said their :)) best interest.

Even if you can get a customer to understand why you are not offering a fixed cost, there will always be some less than admirable salesman who convinces them that their company can.  A person without alot of experience in software development will assume it is a better price as your price comes with an obvious unknown amount of risk, they will more often than not choose the contract from the less than admirable salesman. You don't generally get fired for providing a mediocre solution at cost with a vendor on the line contractually (it is the vendors problem). You do get fired when you are 100,000 over budget in consulting bills with an incomplete project as it becomes your own mismanagement that is the problem.

I am not a lawyer but I would love to hear some legal thoughts on just how to put teeth into these contracts without providing explicit criteria for completion of the contract.  Until I see successfully litigated cases (which there may already be) I am reluctant to even attempt being agile on a fixed price bid.

1) What are your thoughts on the subject?

2) Have you ever been in a fixed price project gone badly where your saving grace was the fact that you did have a full specification document up front that you could reference to show completion and to help side step feature creep?

3) How do we change corporate culture to move away from fixed price contracts?

Posted Fri, Jul 7 2006 2:49 AM by Greg
Filed under: ,

[Advertisement]

Comments

Jason Haley wrote Interesting Finds: July 7, 2006
on Fri, Jul 7 2006 10:41 PM
MarlinlovesDori wrote re: Agile: Fixed Price Bids
on Sat, Jul 8 2006 12:27 PM
I've been on both sides of the fence in software development and currently work for a large real estate firm where I have learned alot about negotiation.  As you have stated, it is all about the contract.  To the non technical groups, it's all about what you have contracted for and any vagaries will unfortunately be used against the other party.  This does not help the party who are taking on the risk of translating someone's ideas into workable code, and as a correllary only compitent people will want clarity, in English.

Unfortunately I have seen marketing groups at my company parse contracts for ways to wiggle out of payment because no one captured "exactly what I meant".  It's ugly as all parties pull out the daggers.  To be honest, marketing deserved to be screwed because they kept the vagaries in the contract and didn't bother to be clear about the concepts.  Ther service provider deserved what they got because they should have insisted on clarity.

You are best served by developing a relationship with a customer who can be an advocate where you can present a hybrid model.  Certain portions of the project will have a finite time frame so you can deliver them at a fixed cost and you should contract separately for those items phases.  

For the big idea stuff, you want a customer who is willing to pay by the hour to have you mentor them and develop the concept, then produce the idea.  Again there will have to be limits and quantifiable chunks.  That's when your methodology will distinguish you from the rest.  

In short, avoid the customers who want a fixed price unless you are will ing to double or tripple your price because what they want doesn't exist .  Be honest - "I am doubling my estimate because it is unclear what you want."  Unless you are willing to do a package implementation, it's a crap shoot on how long it will take to develop ideas and implement.  Protect yourself by avoiding unclear terms.
Rusty wrote re: Agile: Fixed Price Bids
on Sat, Jul 8 2006 12:40 PM
I will have to think about this in more detail as your concerns are all very valid.  I believe the whole concept of fixed price bid is _the_ sticking point.  Comparing software to house building, or bridge building, or physical construction of any kind is misleading.  In physical construction, the construction phaze is 80% or more of the whole project.  The design phaze is a very small, up front exercise that relies on static mathmatical formulas and thousands of years of experience in architecture that have both succeeded and fallen.  The formulas for testing a design can be relied upon and reverified.  Planning, then, is the most crucial skill and variable that will affect profit for the project implementors.  For software, the construction phaze is not writing code.  The construction phaze is compilation and deployment.  Clearly, that's far less then 80%. Furthermore, there are no formulas to test a design other then writing the code.  Software platforms change so frequently that one cannot use historical data to predict the outcome of a project.  Emerging techniques, patterns and frameworks are helping but not solving this problem.  Software is not predicatable in the same way building construction is.  Even in construction, things go differently then planned.  My pop-in-law is taking over a $12 million bridge project paying $15,000 in penalties per day for being late.  The first thing he noticed are two insanely expensive cranes that aren't being used but remain on the project because a set of high voltage lines prevent mobile cranes access to the site.  He asked if anyone had considered paying the power company the $ to move them in order to save substantially more by enabling them to remove the larger cranes.  Wasn't in the plan!  How long will it take to build a house?  How long did it take to build a house of that size in similar conditions?  Pretty reliable, right?  How long will it take to build this software for my company?  Let me go find that same software somewhere else so I can get reliable, fixed numbers.  See the cunnundrum?  There are conditions when fixed price is required.  Then, you must plan and agree upon everything prior to the contract being signed.  However, consultants are not brought in for their ability to adhere to a contract.  They are consulted for their expertise and skills.  A company does not want a contract that matches its language to the product and how long it took to build.  Now really.  They want working software that increases effieciencies, opens new lines of revenue and adds to their bottom line in a positive way.  A fixed-price plan is not designed to predict the outcome of the project, its designed to shackle the client to their understanding of the problem on the first day of the project.  Its designed to prevent new knowledge from affecting the product.  Its purpose is to mitigate the inherent risk in information technology by locking in payment regardless of value.  Most of the time, things go relatively well.  However, I think things would go just as well with smaller plans and less rigid relationships.  Clearly, there is lot to be learned to make this reality
Greg wrote re: Agile: Fixed Price Bids
on Sun, Jul 9 2006 4:13 AM
A few friends told me the house analogy was not a good one before hand but I still used it :( It is not a clean cut analogy you are correct.

Rusty: you make some great selling points against fixed price estimates. I will have to remember these wordings the next time I am forced to deal with it.

The problem does still exist in dealing with the contract though, the hiring company can be shafted on a pure block of hourly time basis. This is one of the things that the fixed price contract does help eliminate as the contract is contingent on working software (usually atleast passing UA testing). I think we can all agree that a huge portion of time is ramp up. If the hiring company loses that consulting firm after say 90 days the next firm will most likely need 30 days of ramp up to be as efficient (not to mention they will want to at the minimum go over everything previously done with a fine tooth comb)

Getting back to our other discussion .. There is still the problem in that many managers etc will outsource projects to absolve themselves of responsibility of the project. This is a problem in many industries but is esepcially prevalent in IT where management often does not have the first clue of how to run a project. If the project comes out well the manager takes full credit for it as it was their brilliant insight and choice of a quality firm to handle the process that made it a success. If it fails it is that the contracting company did not meet the requirements set, ship it to legal. As such we are stuck with a huge corporate mindset problem that I am completely unsure of how to attack ...
DotNetKicks.com wrote Agile: Fixed Price Bids
on Sun, Jul 9 2006 9:57 AM
You've been kicked (a good thing) - Trackback from DotNetKicks.com
bryanallott wrote re: Agile: Fixed Price Bids
on Mon, Jul 10 2006 7:22 AM
"... I am reluctant to even attempt being agile on a fixed price bid ..."

maybe reworded: reluctant to attempt being agile on a fixed price bid where the requirement [solution] is not that clear ?

if you're responding to a RFQ, you're in a position with a fair amount of experience to know wether the project you're looking at is fairly cut-n-dried or if it's going to be more explorative and discovery driven...

if clear, there's nothing wrong with a plan-based approach if the expectations are clear [some clients are quite professional and explicit, even pedantic :), about what they want] and these are easy to approach with a fixed-cost because most of your planning [which itself can be an agile process] is more accurate [more information at hand]- and this should mirror your client's commitment to detail. but this does take some time: and there's no such thing as a free quote [if you want quality] :) - a different discussion?

disclaimer: if your planning process cannot estimate accurately: get better at planning or don't consider a competitively priced fixed-cost project.

if the solution is ambiguous, risky and reliant on discovery for knowledge of the solution... well, you'd be going out on all limbs to accept a fixed-cost without teeth in the contract- but that attitude implemented is what has given software a bad rap.

re the corporate mindset of fixed-cost projects: as solution/service providers, we have a responsibility [duty] to bat a proposal back if it's ambiguous, vague or unrealistic [not even S.M.A.R.T.] and educate the corporate client in the process, via co-operation. historically, i think we failed ourselves as a collective because we didn't have the insight or courage to say no to a lot of projects when we should have- or at least say: wait. let's work this proposal through, together, to get a better understanding becos this is just simply not information to go on.

to perpetuate the house analogy [but with specific respect to the planning phase which is more akin to software]... u can't go to an architect/builder and say: i want a house with a door and 4 windows and i want it at $ by DATE.
their ethical repsonse should be
not until you provide detail [but discovery through co-operation sets you back at $x/hour]
or no- come back when u got an exact idea and save some discovery costs. if they do agree to that kind of spec, chances are, *someone's* gonna get mulled :)

3) How do we change corporate culture to move away from fixed price contracts?
educate the corporate that they can get fixed-price but they must be willing to spend some $$ upfront to get that. provided you're also happy with that and confident in your ability to plan and deliver according to a really good plan- goferit.

and if a reasonable client they can't see why or you can't motivate why spending some $$ upfront for an accurate cost is critical, then abandon the project. there's bigger issues lurking.

it doesn't have to be ALL agile since it is no silver bullet but just a part of the available toolset- but that's up to your team :)
JonGalloway.ToString() wrote Lessons from Home Remodeling: One Week Phases
on Wed, Jul 12 2006 4:58 PM
No, I don't buy into The Construction Metaphor A few times a year, someone will write about howsoftware
raydot wrote re: Agile: Fixed Price Bids
on Sun, Jul 23 2006 1:13 PM
With all due respect (especially because I think this is an awfully important subject) I'm not sure I get this.  I think this type of logic makes perfect sense from the point of view of a coder, but I'm not sure it would make sense from the point of view of a client, namely: "Our shop uses agile methods so we can't make contract guarantees."

I know you're not only saying that, but I can sort of see the appeal of that argument, so that's where I'll go with this.

Having moved from code to project management, if there's one thing I'm sure of it's that each side in an IT project -- client/vendor --  has the obligation to educate the other.  The problem is that all too often the vendor takes the approach that it seems is being mentioned here, "We're gonna learn as we go so it's a moving target."  I just don't think so.  

Before we all sit down to write Client X's payroll system, we're going to sit down and understand Client X's goals in developing a payroll system, and if Client X doesn't know either then the developer shouldn't engage the contract and should be very explicit about that.  The vendor certainly shouldn't at the end of the target berate the client for setting a "moving target," and especially not when this was clearly the case to begin with.  It's only going to end in tears.  Yes some other salesman can come along and say, "We can get it done in the budget you want," let that shop get hung up in the lawsuits afterwards.

What I've also found is all too often the case is that software developers don't protect themselves from the lack of expert knowledge they might have of their client's business process.  I learned this the hard way when I worked with a client that wanted to develop a Web site to sell more of his product.  When the site was built and it didn't sell more product, the client came after us, saying it was my shop's fault his business didn't thrive, until I pointed out to the client that we didn't know a thing about the client's product.  "You're in business to make your gizmos, which means you're in business to sell your gizmos.  I don't see anything over our shop's door or in the contract you signed that says we know one thing about your gizmos -- we know how to build Web sites, and that's it!"  At which point the client had to admit that we'd built exactly what we set out to build.  But all too many developers will (unknowingly) pass themselves off as business experts, and most just aren't.  I now won't have anything to do with a project if the client doesn't seem to understand this.

...and that's what we as software developers have to understand.  I don't buy the "best of all possible worlds" mentality, things can always be made better.  Developers need to be more sympathetic to customers concerns and more clear up front.  Don't expect the client to understand software development, and don't you go passing yourself off as understanding your client's business process -- even if you do.  If project concerns are spelled out explicitly, and constant feedback is provided, there's no need for problems in the long run for either side.  The AIGA has long understood this, and their boilerplate contract is quite good at protecting designers from client folly.
Jay R. Wren - lazy dawg evarlast » Archive » Software is highway and bridge building, not house building. RE: Fixed Price Bids wrote Jay R. Wren - lazy dawg evarlast » Archive » Software is highway and bridge building, not house building. RE: Fixed Price Bids
on Thu, Nov 9 2006 3:22 PM
agile: fixed price bids :: Newstack wrote agile: fixed price bids :: Newstack
on Thu, Dec 7 2006 3:40 AM
On Responsive Development · Agile isn’t about trust… wrote On Responsive Development · Agile isn’t about trust…
on Sun, Jun 1 2008 9:08 AM

Pingback from  On Responsive Development · Agile isn’t about trust…

matt m wrote re: Agile: Fixed Price Bids
on Sun, Sep 14 2008 11:57 PM
I think Fowler's point was about putting stopping points in the contract for the customer. If they are unsatisfied with progress after a release, they can stop the project. If you keep good metrics, you should be able to give an evidence backed estimate of how much work can be done in a time period to assist in the bid process. In reality, incremental development should be a series of small fixed price bids.
Jonathan Parker wrote re: Agile: Fixed Price Bids
on Sun, Mar 15 2009 3:21 AM

I think that trust and collaboration are important which means that the customer is highly involved in the project and thus able to trust you when things don't go right.

On the other hand I think what Martin Fowler was saying is that you fix the price and the time but not the scope, thus in effect it is consulting. Divide the price by the time and you've got the hourly rate. You're basically saying you'll commit to X days/weeks/months of consulting.

links for 2009-09-11 « Csom Gyula Blogja wrote links for 2009-09-11 « Csom Gyula Blogja
on Fri, Sep 11 2009 6:07 PM

Pingback from  links for 2009-09-11 « Csom Gyula Blogja

uberVU - social comments wrote Social comments and analytics for this post
on Wed, Feb 3 2010 10:55 AM

This post was mentioned on Twitter by ravinar: Fixed Price Bids and Agile - the conundrum http://is.gd/1doQ7 I am again reading around the topic that always rears its head...

Add a Comment

(required)  
(optional)
(required)  
Remember Me?