Many buyers of IT development projects seem to think that all problems and unpleasant surprises can be avoided by buying a fixed-price, fixed-time, fixed-functional contract. My experience, however, is that if you haven't built enough trust between buyer and supplier you will at some point, often late in the project, end up in endless discussions on what was really part of the scope and how to interpret the requirements written in the contract. This is just natural since both parts, lacking trust for each other, are focusing on maximizing their own profit from the business relationship.
In the agile world one giant step forward has been taken - to embrace change. This results in fixed-price, fixed-time, fixed-functional-effort contracts where decisions on functionality can be deferred and revisited in each iteration. This gives the buyer the benefit of actually receiving what they need instead of what they thought they would need in the future by the time of contract signing.
However, even in the agile approach you may end up in long discussions on how to define the effort of any given feature to be implemented - if you are in a non-trust-relationship that is. I think that relationships between organisations aren't any different from relationships between people. It is just not possible to base a lifetime of living together with another person on contracts. It has to be based on deep and honest trust that both parties honour.
So, before you decide to by an IT development project from a vendor, decide on whether the vendor is to be trusted. Also try to find out if the vendor has trust in you as a buyer. If so, go forward, form a common goal and sign the contracts you think are necessary for guidance. But do not try to build a relationship on contracts if you are lacking the trust.
I came by an interesting article on agile contracts. Thought I should share it.... http://www.infoq.com/articles/agile-contracts
ReplyDelete