Greedy computing with API

Myth of fixed price contracts:

Typical understanding of a fixed price contract is it transfers the risk to the vendor. Yes, it does transfer some risks to the vendor. But not significant one’s unless vendor is foolish and suicidal. Let us analyze fixed price contract.

Perceived benefits to customer:

a)     Risk is transferred to vendor

When a fixed price contract is given it is agreed that vendor will deliver the project at that cost. Whatever issues vendor experiences, he is bound to deliver the results. There can even
be penalty clauses for delays in delivery.

b)     Budget is fixed. No more bureaucracy.

You got the budget approved for the project. There is really no worry to get extra money sanctioned for the project from the head office. This may not be issue with many organizations, but for some this is a serious issue. Getting new amount sanctioned during the year will take more effort than getting new project sanctioned. This is a political reason in few organizations.

c)      Delivery date is fixed

It is defined in contract. If it is T&M contract customer tends to make some changes and end dates shifts. FPC contract acts a self regulation. This deters the customer from making changes to the project.

d)     Not my headache to meet deadline.

Vendor has taken the responsibility to meet the deadline. There is incentive to the vendor to deliver on time. This ensures delivery is done on time.

Risk for customer:

a)     Need to pay more for changes

If you missed something in the initial requirement then you will have pay a lot for the changes. Usually
change requests in a fixed price contract costs more. Vendors will always tell change will impact the system and there are many places which require change etc. Vendor also mentions testing entire product after the change. There is reality in this argument. When vendor does a FPC project this will be done phase wise. This saves money for the vendor. There is no need to develop automated tests.
This is how vendor saves money.  In this model changes cost more. Ideally  FPC projects should not have significant changes.

b)     No second thoughts

Once the contract is given then you will need to pay the contract amount. Unless there are terms defined for breaking contract you are bound by the contract.

c)      Cannot make changes

Even small changes need to be made as change requests. Even if you do not want a big portion it is difficult to make changes to the contract and reach new agreement. Typically vendor would
have finished a phase when the changes come in and it is pain for vendor to make changes. They will not agree unless there is a benefit to them.

d)     Need to pay for obsolete requirements

By the time project is complete some of the requirement are obsolete. It is a waste of effort and money.

 

Benefits for vendor:

a)     Scope is defined

Vendor has benefits in this model. Scope is defined. And he can plan and develop. This helps in maximizing profit.

b)     Functionality is well defined?

Many times customer does not come prepared. They have rough idea on what is required. 

c)      Monetary value is defined

It gives the management ability to plan. Hiring new people planning for new projects etc becomes easier because of the fixed contract.

Risk for vendor:

a)     Not able to finish on time

If vendor cannot finish the project on time then the penalty can be applied (if it was in contract). This will wipe off all the potential loss for the vendor.

b)     Ambiguous scope can kill

If vendor is not careful to analyze the scope then this will be a killer. Sometimes customer can push the vendor into accepting the project with promise of clearing the scope. Vendor will be
bankrupt before the project is complete if it is a FPC which should not be a FPC.

Is it worth going for FPC.

a)      Yes, if the project is done earlier.

b)     Yes, if the business requirement will not change.

c)      Yes, if the project is routine kind of work.

d)     Since all the above does not hold good for most of the projects, it is a no.

Most IT projects are not done earlier. They are unique. They have different requirements. They require different approach and different understanding. It is not an assembly line production. IT project is like
building a monument or building a house. Each one has different specification. Best way to develop a product is to let the people use their creativity in a controlled way.

But why there are so many contracts which are in FPC? All other contracts also have similar issues. We do not have a better way of working till now to exploit the value generated by the product. It is not easy
to overcome mistrust and greed.