Software development projects can be carried out in various contractual constructs. At AOE we prefer “Team and Method” contracts. One of many reasons is that customers can only benefit from experience curve effects with this approach. Let me explain why.
Actually, the concept of the experience curve shouldn’t surprise anyone. It basically states: The more experience a company has with the production of an item, the more efficiently it can produce it. The accepted rule-of-thumb: If a company doubles its cumulative production volume, then the per-item costs are lowered by 20 to 30 percent. The Boston Consulting Group, in particular, was able to empirically verify this effect in the 1970s.
The experience curve effect can likely be attributed to several factors. For one, an additional learning effect takes place with each item produced – employees and the organization learn to implement processes much more efficiently. Secondly, growth leads to specialization, which in turn amplifies the learning effect: A person that carries out two tasks in eight hours gains only half as much experience in both tasks as two people who carry out one task in eight hours.
Because of this effect, industrial companies have a vested interest in achieving a large share of the market as quickly as possible; in this way, they can reach a higher output volume in a shorter time frame. High market shares and output volumes enable a company to offer its customers a more favorable price. Thus, the company can achieve even more market share or create market entry barriers for the competition – or earn higher margins. In this context, a higher market share can be equated with a strategical competitive advantage.
Now, it isn’t as if we, as software- and IT service providers, assemble ballpoint pens. Every project is different and requires the creativity of every employee. Our projects are successful especially because we work with cross-functional teams and very rarely rely on pure-play specialists.
Does the experience curve effect even exist for software services?
At least Tuckman’s model for team building and the stages of group development seems to support this view. After all, a team can only reach the Performing Phase through jointly accumulated experience. Thus, the “produced quantity” here is the sum of the collective project hours worked on or the sprints.
The result? The team can deliver the product faster or with a higher quality – or both.
However, the customer doesn’t benefit from these effects in traditional fixed-price projects (your deliver requirements A-F for a sum X). After all, the service provider has a huge incentive to cut costs because the price is determined in advance. This can only work if quality is sacrificed and features are developed in as short a time as possible – regardless of whether they make sense. Thus, experience curve effects in fixed-price contracts provide large economic incentives to deliver a product with inferior quality.
This is another reason why we primarily work with “Team and Method” contracts, wherein the scope in particular remains variable.
In this case the customer has massive benefits from the team’s experience curve effects: He can decide during the project if he wants to improve quality or broaden the scope of a release – without the service provider manipulating the margin.
From the point of view of the service provider, this construct offers another advantage – beyond the security of a predefined margin: The team can truly become part of the customer, for the customer has a vested interest in the team’s performance. Suddenly, a true partnership is created, not a customer-service provider relationship between the two parties. And this occurs without a lot of effort, simply through the structural conditions.
What it comes down to is this: Whoever wants to take “Customer collaboration over contract negotiation” seriously, must work with “Team and Method” contracts.