Fixed-price fixed-time, time-material or managed time-material software delivery models - they are all ultimately primitive. They are full of co-operation anti-patterns, promote negative habits and may turn potentially destructive both for Clients and Software Vendors. As you might have experienced or as you can imagine exploiting vulnerabilities built-in the above models happens on regular basis. In a case of fixed-price model the Client is potentially benefiting from the weaknesses of the model. On the contrary, it is the Software Vendor who is a beneficiary of the time-material model’s constraints / assumptions. Tendencies for exploiting vulnerabilities origin from various reasons and exist on both sides. Well, this comes at no surprise as intelligent human beings tend to adapt to surrounding environment. Mary Poppendieck’s Lean Software Development gives an excellent insight into the subject.
I will not be surprised if fixed-price and time-material models are the only delivery models you have ever come across in your carrier. You must be extremely lucky if you actually had a chance to work in some other models. You might have come across a composition of a fixed-price from the client perspective mapped onto Agile model used internally by a Software Vendor. This is very popular approach, but it does not gain from the synergy between Client and Software Vendor offered by Agile.
Yet the fixed-price fixed-time model have dominated the market. Background of this phenomenon is composite, but in my opinion two reasons constitute the backbone of mental background for their domination.
First of all, at the inception of software management people applied production models existing in other branches of industry and transferred them directly into software development. This is described by Frederick Brooks Jr., in The Mythical Man-month. Such decision makes sense at first sight, however with time the understanding arose of its limitations. The cardinal flaw of such approach was that software development is a creation process rather than a production process. This has severe implications on applicability of production models to software development. In fact, as noticed by Ken Schwaber in the Agile Software Development with Scrum - the nature of software development is too complex and cannot be handled by production processes as they are suitable to control well-defined processes. On the contrary software creation is so complex and unpredictable that empirical process control should be chosen for dealing with it.
The second reason for domination of fixed-price fixed-time model is business model at client organizations. Typical Clients of a Software Vendor are usually very busy and hard-working people, experts in their domain of specialization. Clients have internal clients, usually their bosses who originate the project. To get an anual bonus a typical Client need to make a project happen within a given deadline and within a fixed budget. The budget is available during the current accounting year and no longer. A natural approach for a Client is to agree with a Software Vendor on a scope of what can be delivered for some fixed-price and in some fixed-time. This is exactly the background of the fixed-time fixed-price delivery model. Of course requirements are fluid and a lot of areas are not thought through at the moment of signing a contract thus opening the doors to all evil to come. A Client leaves the project to Software Vendor to deal with it, because (s)he has a lot of other duties and (s)he is pretty certain that (s)he transferred all risks onto the Vendor - after all the Vendor will not get paid if something goes wrong, right? When a Client comes back shortly before deadline, (s)he usually gets something different than what (s)he expected. We all know the story… What is more, in this very moment a Client realizes that the risk was never really transferred onto Vendor! Yes, there will be consequences to the Software Vendor, nonetheless and in spite of how high they are, they will not cover concequences of a Client side - consequences for each party are of different nature and are most commonly separate. So what the Client really did when signing a contract was to create new risks on the Vendor side rather than transfer any of the Client's risks onto the Vendor side.
Anyway, did you notice how natural fixed-time fixed-price approach appeared to a Client?! Thinking in categories of what can I get for my money and when it can be delivered is as natural as checking the price of a product in an internet shop!
And yes, another eye-opener - the goals of Software Vendors in a fixed-time fixed-price delivery model are to deliver working software in an agreed scope, according to the agreed schedule and within the agreed deadline. No less no more. Do not get me wrong - the respectful Vendors always tend to deliver the best product possible including also other aspects, but usually hardly have any chances to cover anything extra due to tight budgets and deadlines. Exactly these deliverables result from the nature of the model. I encourage you to think of all aspects of the delivered software not covered by these three constraints. Scary! But again, does it surprise you? Isn’t it a natural choice for Software Vendor? As said above - intelligent creatures adapt to surrounding environment and in this case an environment of choice is fixed-price fixed-time model.
It takes a highly aware client to choose other delivery models. Recognition of Agile models is still very limited although it is probably the most attracting marketing slogan used nowadays by Software Vendors. In spite of 10 years on the scenes and tremendous amount of Agile mentoring done by Agilists it is not widely used by Clients (except from usage as marketing tool). An advice of Ken Schwaber given in the above-mentioned book to persuade Client to use Agile is not that easily applicable.
