“Keeping you up to date with everything software engineering!”

Problems with Fixed Price/Fixed Scope Contracts

Project Management | October 01, 2004 | 3 comments

When I used to do contract work the one thing I hated the most was writing up a quote. Not because I am not comfortable talking about money but because I knew that no matter what price I told my client it would not have anything to do with the real cost of the system. I really had only two options when I quoted:

1. to quote a price that would guarantee me that I would get the project or;
2. to quote a price that would protect me because the project was not even close to being fully understood not only by me but more importantly by my client.

With option one I would get the contract and with option two there was a very slim chance. But either way, both options did not give an accurate price of what the project would cost to implement not because I did not want to give an accurate estimate but because I couldn’t.

Lawyers don’t charge you a fixed price when you hire them to represent you other then a fixed cost per hour. Why not? Because they have no clue how long the court case will last! A home builder will not tell you how much it will cost to build you a house until they get the plans including all the details on what options and accessories you are going to choose including the type of roof, model of kitchen and type of floor. If you say well I want a 4 bedroom house with 3 bathrooms, 1 kitchen and 1 living room they still could not tell you how much it will cost because the requirements are still too high level.

Hal Helms was the first person to introduce me to the concept of only quoting after you have built the front-end/prototype of a system and it is frozen because only then will you truly know the requirements of the system. So does that mean that you build the prototype for free? Not at all, if I remember correctly Hal suggested that you charge per hour to determine the requirements of the system. Of course if you know the budget is in the low tens of thousands and the prototype is starting to look like the application is going to cost millions you warn your client and you reduce some of the requirements. You have to take into consideration some of the constraints like budget when building a prototype.

Then I read this week Martin Fowler blog entry “FixedScopeMirage” and “FixedPrice”. I agree that by fixing the scope you are going to run into a problem early on in a project for the most part just because you don’t really know what the scope really is. So instead of fixing the scope why doesn’t one fix the budget and see where they can go within the scope of the budget?

Well, there are many problems with that model. For instance, if you are using the waterfall model to develop your software then you might run out of money during the design phase and hence have nothing to show for it. You would have no choice but to use an iterative model while choosing an iteration length that will allow you within budget to go through at a minimum two iterations. But then again waterfall was never a very good methodology to begin with.

Now I have to put my business hat on and ask me if this will work. As a business man would I ever choose Company A who comes in with a quote of $10,000 and says that they will do as much as they can within the context of the budget over Company B who says they will be able to finish the project for $10,000. As a businessman choosing Company B sounds like the much safer choice. But soon as I put my software engineering hat on again I get scared of Company B because they can’t possibly give me something that will pass acceptance testing. They might give me something that does what my high level requirements stipulated but I am sure that the users will not accept the system.

So what are we to do as Software Engineers? If you ask me when we choose to enter a brand new field as pioneers we took on our shoulders the responsibility to not only practice software engineering but to teach people the importance of software engineering and what good software engineering constitutes. If slowly the Company B’s out there disappear and clients are having more successful software projects with Company A’s then it will soon become not only accepted but preferred that we can not fully quote a price until we fully understand what your needs are. That determining what your needs is a good thing for both you and I.

For the business people out there, if someone is quoting you on a software project only after meeting you once or twice I would be scared if I where you. It is a good sign that the person who is going to develop a business system for you is going to fail at doing it with a very high percentage of accuracy. It is not that the company does not want to know what your true requirements are, they just don’t know any better.

For the software engineers out there, please don’t do fixed price/fixed scope projects. You are just messing it harder for the rest of us to do our job well.

Related Links:

• Hal Helms
• FixedScopeMirage
• FixedPrice

Help Support Us By Visiting Our Sponsor

10% of our revenue from these ads go towards scholarships!

Comments

October 3, 2004 12:51 AM | ElvisIsGod commented:

Rather weak arguments here…

Not all Software Engineers are the same in terms of speed, quality and experience. Should you get a “graphic artist” and just pay them by the hour without knowing what you will get? If you hire someone to do a logo, do you just say it’s “x”$/ per hour and you just pay hoping that you will get something that you like? And if not, well at least he picked out a nice font…

Development can’t be open ended like you would like - it makes no business sense.

As an example, say you are hired to build a login section for a web site. It sounds like you would like Mr. Business Man to give you all the specs with all details, user examples, SRS, UI models (all this should partially be your job) and then you will try to deliver it and if you can’t, he will have to pay more…

You can’t expect Mr. Business Man to pay you for your learning, your mistakes…

Any job/project should be a collaboration - there lies the value. If not, it’s just as easy and less expensive to outsource overseas…

October 3, 2004 12:49 PM | John Kopanas commented:

I think the fault in your argument is that your a comparing a logo, which already has a definitive definition to what it contains, and a software system where there is an infinite amount of interpretations. Even when someone creates a logo for you they ask you a couple questions to narrow it down to exactly what you want and then tell you they will create X amount for $Y and you can choose from them. It is like you asking me to create a login page I create you 3 of them for $Z and then tell you to choose one even if none fit your requirements.

I don’t feel it is my clients job to give me all the specs. That is the job of a requirements engineer. But a requirements engineer is a consultant and should be paid hourly like one.

If you outsource overseas you will have the same failed project but for cheaper. You will get a product that does something but unfortunately in most cases you will not only get something that does not do what you want it to do and fails acceptance tests but you will loose the time you spent making something that does not work. Why not do it right the first time for less money over the long run. Oh I know… so smart start-ups can overtake companies that don’t evolve.

Yes everyone is not equal… that is why you pay different people different hourly wages. Elvis… is every graphic artist the same?

October 3, 2004 12:51 PM | John Kopanas commented:

I totally agree with collaboration to determine the needs. All I am saying is that you can’t quote on something you have no clue what it will do and that you can not expect a client to even know what it does by looking at specs. You need something they can play with.

Post Your Comments

Comments:

Name:

Email Address:
(note: not displayed)

URL:
(note: displayed with comment)