In Process Design is Never Finished I raised the issue on how to align the contract terms to allow for multiple implementations based on user feedback when using external service providers. In most cases, contract negotiations are usually focused on the total level of effort for a specific deliverable based on a given requirements documents. The underlying issue is that change requests are formally defined and actual work against BPM type projects. Why?
The more feedback – the more change orders – the higher the cost.
Since we now agree that feedback is required to achieve a good implementation we need to change the contract terms in order to benefit from the feedback. My idea is to add "iterations" language into the contract with possibilities of 3 or 4 iterations to be completed before change order language kicks in. The first iteration would be a delivery as close to the original design specification as possible. Subsequent iterations would be based on feedback and reviews of the previous iterations.
By approaching this from a contract standpoint, negotiations with the service provider would be focused on the total level of effort, the number of iterations that will be completed, and the percentage of the level of effort required for each iteration. These negotiations will be based on the quantity and quality of the initial requirements, the experience of the service provider, and the flexibility of the BPM application. For example, a very detailed specification may result in an allocation of 70% of the effort on iteration 1, 20% of the effort on iteration 2, and 10% on iteration 3. When only minimal requirements are at hand, four iterations may be best with equal breakdowns, i.e. 25% each. The more experience the service provider is in a specific knowledge domain the more accurate their work effort percentages will be.
Next up – can we use this model during the selection stage when picking a BPM Application?