Fixed Price Contracts

Few days back Sajjadul Hakim posted a topics in SQA Bangladesh Group about "Fixed Price Contracts". I thought it will be nice to post in this Blog to focus the topics he discussed already. Here a pasted the whole topics with detail URL. Please feel free to discuss on this issue in the SQABD group if you are interested.
____________________________________________________________


Fixed Price Contracts

When does your project start failing? The day you accepted the project.

Most projects worked in Bangladesh are fixed price contracts.

A fixed-price (FP) contract between a provider and a customer defines
the scope, features, planning, timing and price of a software project.
Pretty much everything is fixed, not only the price.

How do you make sure you are not walking into the lion's den? There is
a good article on projects that are based on fixed price contracts,
called "Agile Fixed Price Projects part 1: The Price Is Right". You
can read it here (PDF attached):
http://groups.yahoo.com/group/sqa_bangladesh/files/fixedpriceprojects.pdf

In the following I tried to write a summary with some comments to
influence you to read the entire article. Here goes…


# There is a project in the horizon…Do you qualify…
----------------------------

Question 1: Do I know the domain?
You can't really estimate and develop the software within deadline if
you are new to the domain. The software is all about providing a
solution to the customer. It is very difficult to do that if you have
no experience in the domain.

Question 2: Do I know the technology?
It is not practical to experiment with new technology and tools when
you have a deadline to meet.

Question 3: Can I work with my usual team?
Get the project signed off. Now hire engineers to form the team. This
is a recipe for disaster. You can't really estimate efficiency and
performance of engineers if you haven't worked with them.

Question 4: Can I handle the estimated project size?
If you and your team have worked on short projects, you will be taking
a huge risk undertaking a long project. If you have worked with small
teams, you will be taking a huge risk managing a big team.


# Hooray, you qualify…Should you accept the project…
--------------------------------

Sales tip 1: Don't just respond to "Request For Proposal" (RFP)
Let's talk about our government. Government floats tenders with RFP
document for software projects. Software companies (vendors) submit
their bids based on the instructions in the RFP document. The proposal
contains specification, timing, planning and price. The government
chooses the best proposal (yeah right). Always get more info from the
customer personally before creating the proposal, since the RFPs are
incomplete. You must do this to estimate better.

Sales tip 2: It works both ways
You will have a deadline to meet. That means you will need certain
info and feedback from the customer within certain timeframes or else
you may miss the deadline. So add these conditions in your contract,
i.e. the customer should deliver some information by a certain date;
provide testing feedback within a certain date etc.

Sales tip 3: Don't underbid
If you know how much the project will cost, then don't underbid just
to throw off your competition. How will you compensate for the loss if
you win the project? By giving the customer less than they asked for?
Good luck with that.

Sales tip 4: Add some slack to cover the risks
Your estimates are always flawed. Accept it. Keep buffer time. Don't
cut your buffer to underbid your competitor.

Sales tip 5: Real business requirements
Write the specification with the customer. If the customer is
reluctant to give you enough info, then chances are he will do the
same after you get the project. In any case, you don't have enough
info to estimate. If you go through with it you will probably fail the
deadline.


# Got the job…Rough ride ahead…
--------------------------------

Implementation tip 1: Don't allow change requests
I don't want to comment on this. Better read the entire section in the
document. Here is a quote from the doc: "Don't use Change Requests
because their drawbacks heavily outweigh any initial advantages they
bring"

Implementation tip 2: Spend your slack wisely
Things will go wrong. Prepare for it. Use your buffer time wisely.
Leave some buffer for the end. Usually that's when the heat is on.

Implementation tip 3: Simple, honest and correct tracking
Remember the Green Shift Anti-pattern in one of my previous post? Look
it up here:
http://groups.yahoo.com/group/sqa_bangladesh/message/431

Implementation tip 4: Manage your project
Be proactive. Let the team solve problems with you. Let the team
interact with customers. Stay alert for creeping issues.


Now I am done…for now at least. Deadline oriented projects are always
high risk. The above steps should minimize the risks involved.

This may work for you if you are getting projects abroad. But let's
face facts…you won't really get too many projects that fit all the
criteria in Bangladesh. The author has created another article that
brings a little agility to fixed price contracts. Will post that
later. Thanks.

Regards,
Sajjad


_______________________________________________
source: SQA Bangladesh (www.sqabd.com)