Skip to main content Skip to Footer

BLOG


August 25, 2016
How to structure Agile contracts with system integrators
By: Mirco Hering
In my role as a systems integrator, I spend a lot of my time responding to proposals for projects. I am also spending time as consultant with CIOs and IT leadership to help them define strategies and guide DevOps/Agile transformations. An important part is to define successful partnerships. When you look around it is quite difficult to find guidance on how to structure the relationships between vendor and company better. In this post I want to provide three things to look out for when engaging a systems integrator or other IT delivery partner. Engagements should consider these elements to come to a mutually beneficial commercial construct.


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.

Focus on Day Rates is Dangerous

You should therefore look for contracts that work on overall cost not day rates.  

Tweet it. This opens a new window.

 



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.  

Tweet it. This opens a new window.




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 past

In 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.  

Tweet it. This opens a new window.




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.

Popular Tags

    More blogs on this topic

      Archive

        Topics highlighted

        Applications