A Fixed Price Contract

A fixed-price contract between a vendor and a customer defines the scope, features, planning, timing, quality, change, deliverables and cost of a project.

Why do customers often demand these fixed-price contracts? There are many good reasons:

ü  Customer’s prerequisite to know scope, timing and price to choose between bids in a multi-provider bidding process.

ü  Customers think that they take no functional risk: if the vendor does not deliver what was agreed, the customer can always refuse to pay, or even sue! Of course, if the customer really needs the deliverables on the given date, then suing does not solve their troubles.

ü  Customers think they take no financial risk, as the fixed price is known at the project start.

ü  Customers prefer a defined, planned and sequential project flow that gives them a warm, safe feeling of control—that is, until near the end of the project, when these projects so often suddenly start to fail.

Why would I want to do Fixed-Price Projects?

ü  Because of the fixed schedule, Vendor can more easily plan different projects.

ü  Because of the fixed schedule, Costs are predictable.

ü  Because of the fixed budgets, the income of Vendor is predictable.

ü  Some customers are more likely to spend time thinking about their real requirements, making tough decisions to avoid threats to the budget or schedule.

Frequent Releases, Incremental Delivery

When working on software development projects, It is obvious to release the software often. Typically, the software will be released quarterly to the customer, as agreed during the sales process. The team gives a demonstration of the new features, and then the customer uses these releases to do acceptance testing. The customer then gives feedback within a defined delay; the team acts upon this feedback before implementing new features.

ü  The development team acquires the dangle of releasing the software, with all the messy junk related to installation, database upgrades, and backward compatibility.

ü  The development team emphases on delivering high quality complete features. Each time the customer accepts a feature, the team gets a little buzz of satisfaction.

ü  The customer can test and accept features incrementally. Each week, some new features are available for testing. All the testing work (and its valuable feedback) is not delayed until the end of the project.

ü  The customer can give useful feedback from the beginning of the project. They learn a lot from seeing and using the actual product. This knowledge can be used to improve the rest of the project.

ü  The customer has a real sense of progress.

ü  The finished features you remove from the totals in your "burndown chart" are accepted by the customer. The chart will therefore better reflect the amount of work actually done.

Many Small Projects are Better than One Big Project

It is a well-known fact that project success rates are higher for small projects than for big ones. Small projects are easier to oversee, require fewer people, handle fewer requirements, have smaller estimation errors, and lead to tangible results faster.

Often, customers are surprised when I do this; however, there are many advantages for them:

ü  Project cost is reduced if we can drop or postpone some features

ü  Users get the software earlier than expected

ü  Project risk is reduced as we work on fewer requirements and concentrate on the high value features

ü  Customers can evaluate the outcome of the project sooner

ü  Customers can delay their decision about dropping requirements from the first release. Closer to the release date, the customers will have more information with which to make a better decision.