A focus on day rates is dangerous
We all know that more automation is better, why is it then that many companies evaluate the "productivity" of a vendor by their day rates. Normally organizations are roughly organized in a pyramid shape (but the model will work for other structures as well).
It is quite easy to do the math when it comes to more automation. If we automate activities, they are usually either low skilled or at least highly repeatable activities which are usually performed by people with lower costs to the company. If we automate more tasks that means our "pyramid" becomes smaller at the bottom. What does this do to the average day rate? Well of course it brings it up. The overall cost goes down but the average day rate goes up.
|You should therefore look for contracts that work on overall cost not day rates.|
A drive for lower day rates encourages manual activities rather than automation. Besides day rates, it is also beneficial to incentivize automation even further by sharing the upside of automation (e.g., gain sharing on savings from automation, so that the vendor makes automation investments by themselves).
|To this date many organizations structure contracts around deliverables. This is not in line with modern delivery.|
In Agile or iterative projects, we are potentially never fully done with a deliverable and certainly shouldn’t encourage payments for things like design documents. We should focus on the functionality that is going live (and is documented) and should structure the release schedule so that frequent releases coincide with regular payments for the vendor. There are many ways to "measure" functionality that goes live like story points, value points, function points etc. Each of them better than deliverable based payments.
Here is an example payment schedule:
We have 300 story points to be delivered in 3 iterations and 1 release to production. $1000 total price
10%/40%/30%/20% payment schedule (with first payment at kick-off, second one as stories are done in iterations, third one is once stories are releases to production, last payment after a short period of warranty).
10% = 100% on Signing contract
Iteration 1 (50 pts done): 50/300 *0.4 * 1000 = $66
Iteration 2 (100 pts done): 100/300 * 0.4 * 1000 = $133
Iteration 3 (150 pts done): 150/300 * 0.4 * 1000 = $201
Hardening & Go-live: 30% = $300
Warranty complete: 20% = $200
BlackBox development is a thing of the pastIn the past it was a quality of a vendor to take care of things for you in more or less a “blackbox” model. That means you trusted them to use their methodology, their tools and their premises to deliver a solution for you. Nowadays understanding your systems and your business well is an important factor for remaining relevant in the market. Therefore, you should ask your vendor to work closely with people in your company so that you can keep key intellectual property in house and bring the best from both parties together, your business knowledge and the knowledge of your application architecture with the delivery capabilities of the systems integrator. A strong partner will be able to help you deliver beyond your internal capability and should be able to do so in a transparent fashion. It will also reduce your risk of nasty surprises.
|And last but not least in Agile one of the most important things for the delivery team is to work closely with business.|
That is just not possible if vendor and company are not working together closely and transparently. A contract should reflect the commitment from both sides to work together as it relates to making people, technology and premises available to each other.
One caveat to this guidance is that for applications that are due for retirement you can opt for a more traditional contractual model, but for systems critical to your business you should be strategic about choosing your delivery partner in line with the above.