Today I got an interesting question about how our company deals with fixed scope/price contracts. Here's my slightly enhanced reply :-)
To say right from the beginning - we have never done a fixed scope contract. We have done fixed price contracts, but none of the systems we've ever done (from small CRM for 2 people company to quite large systems spanning geographical locations, departments, etc.) has ever turned up the way it was originally "envisioned" by the customer. And that applies even to systems that were replacing some existing systems and we could work with the original developers/domain experts who knew precisely what they wanted. In fact, it applies even to systems we built for ourselves :-). Our first release comes usually after 1 week and by 3rd week the customers usually have a completely different idea about what they really need and, especially, what is possible. I would even go as far as to say that if the system is delivered the same as originally requested, there's something wrong.
As such, our contracts with customers usually define the system only on modular level with “hints” of the most important specific functionality requests. It may sound funny, but the details are going to change anyways. (more about it can be found here Fixed Scope Mirage) I usually get asked how we decide what to work on if the scope is so vague. This is very simple – it's always decided by users' priorities. And at the end, it's the business priorities of users that will define the scope of the system.
Is it always possible? Definitely not. It really depends on the personality and experience of your users. It's going to be really hard for someone who's never done anything with accounting to define what his accounting system should do. Most probably the worst category is users (or customers) that don't care. In those cases I would rather suggest an off-the-shelf system. Another situation when it's really difficult is when there are no real users yet. The crucial point here is instant communication and working directly with the actual users (for us at least once a week). Of course, to do that you need to be "releasing" daily (depending on the phase). Our customers also have access to our issue tracking system so at any time they know what we're working on and how long it takes.
Now to the more difficult question...fixed price contracts. How do you put a price on something that nobody knows what it is? It's possible to have a fixed price even in agile project ( Fixed Price) and I must say that most of our projects start with the fixed price. We do it either by specifying a subset of functionality that the customer believes is well defined and we do that first. When/if we deliver or when the customer gets the touch and feel of what we do and how we do it they decide to go on with the scope at which point we provide another quotation (with usually much better conditions). The second way - in case the customer simply wants the whole system we simply agree on the buffer that will have to cover the difference. Once the buffer is over, we wrap up and the rest is negotiated/quoted and invoiced separately. Regardless of that, however, our payments are always progressive - by iterations. At the end of the iteration the payment is made and we continue only after we've received it. Of course, doing the above will effectively ruin the time plan. There are countries, however, where you need to be really careful and we require deposit. Of course, that is not to say that we've only had perfect contracts - regardless of the contract, there are always challenges. The rule of thumb is get something done and get the money.
Having done projects in several countries in Asia and Europe I must say that contracts vary really a lot depending on the given country/culture/legal system and so on. Whereas in Europe everybody requires 20 pages legal document that is handled by lawyers, in most of Asia the contracts are worthless and the only thing that matters is money in the hand.
No comments:
Post a Comment