The Customer Drives the Car
I talked with a friend, who is a very, very good programmer, about why it is so hard to find sane management practises in software development projects. Most project managers I meet (with a few shining exceptions) know very little about good management practises and process control.
My friend mentioned that IBM is moving to fixed price contracts for most of its subcontractors, and said he hopes other customers will follow. He pointed out that with time and materials contracts, there is no incentive for custom software development companies to improve their practises.
I believe he is right. I am no friend of fixed price contracts. Most projects have considerable feature creep, not just because of sloppiness, but because new requirements are discovered during the development process. There may be no way for the customer to know at the outset of the project that a particular feature will be needed. For this reason, I am more in favor of other contract types, like staggered contracts, profit sharing, target cost, and target schedule contracts. Generally speaking, all of these are more suited to software development than time and materials or fixed price contracts. (All of these feature negotiable scope, which is a key to success when developing software.)
Still, fixed price contracts do provide an incentive to do the work in a professional manner, so they would force the industry to shape up a bit. There are also ways to reduce the risk of fixed price contracts.
The important thing here is that the incentive to change must come from those who have power and something to gain from a change, and that is the customers. This thing has happened before, in the automotive industry. When Toyota went Lean in the late forties-early fifties, they simply refused to make business with subcontractors, unless they to went Lean.
The thing that made this actually work, was that Toyota sent their own Lean experts to their subcontractors, and helped them reorganize their companies and their manufacturing processes. It is as Kent Beck wrote, "the customer drives the car".
The nice thing about this, is that the subcontractors ended up more profitable than before. The scary thing is that they resisted becoming more profitable until they were forced by their main customer. Even scarier, many software development companies are doing that now.
On the other hand, some software companies are getting it. Microsoft has had great success implementing Drum-Buffer-Rope in an IT department in India. (And here is a presentation slide version.)
Now, if I could find a software development company interested in doing the same kind of thing where I live... (If you just happen to work at such a company, why not email me.)
My friend mentioned that IBM is moving to fixed price contracts for most of its subcontractors, and said he hopes other customers will follow. He pointed out that with time and materials contracts, there is no incentive for custom software development companies to improve their practises.
I believe he is right. I am no friend of fixed price contracts. Most projects have considerable feature creep, not just because of sloppiness, but because new requirements are discovered during the development process. There may be no way for the customer to know at the outset of the project that a particular feature will be needed. For this reason, I am more in favor of other contract types, like staggered contracts, profit sharing, target cost, and target schedule contracts. Generally speaking, all of these are more suited to software development than time and materials or fixed price contracts. (All of these feature negotiable scope, which is a key to success when developing software.)
Still, fixed price contracts do provide an incentive to do the work in a professional manner, so they would force the industry to shape up a bit. There are also ways to reduce the risk of fixed price contracts.
The important thing here is that the incentive to change must come from those who have power and something to gain from a change, and that is the customers. This thing has happened before, in the automotive industry. When Toyota went Lean in the late forties-early fifties, they simply refused to make business with subcontractors, unless they to went Lean.
The thing that made this actually work, was that Toyota sent their own Lean experts to their subcontractors, and helped them reorganize their companies and their manufacturing processes. It is as Kent Beck wrote, "the customer drives the car".
The nice thing about this, is that the subcontractors ended up more profitable than before. The scary thing is that they resisted becoming more profitable until they were forced by their main customer. Even scarier, many software development companies are doing that now.
On the other hand, some software companies are getting it. Microsoft has had great success implementing Drum-Buffer-Rope in an IT department in India. (And here is a presentation slide version.)
Now, if I could find a software development company interested in doing the same kind of thing where I live... (If you just happen to work at such a company, why not email me.)
Comments
I've considered profit sharing, for example, but realized that I didn't know a way for me to know what my client might be making in profit.
The easiest way to find out how much money your customer makes, or expects to make, is to ask. If the customer is reluctant to answer, I would argue that you have not yet established the trust necessary for a profit sharing contract.
It is important to remember that both parties must regard the endeavor as a joint-venture, not a work-for-hire, for a profit sharing contract to work.