How to Structure Agile Contracts with System Integrators

As you know I work for a Systems Integrator and 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.

Focus on Dayrates 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 dayrates. Normally organisations are roughly organised in a pyramide 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 dayrate? Well of course it brings it up. The overall cost goes down but the average dayrate goes up.


You should therefore look for contracts that work on overall cost not dayrates. A drive for lower dayrates incentives manual activities rather than automation. Besides dayrates it is also beneficial to incentivise 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)

Deliverables are overvalued

To this date many organisations 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 (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. 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.

I already posted some related posts in the past, feel free to read further on:

8 thoughts on “How to Structure Agile Contracts with System Integrators

  1. Neill Turner

    Good comment about day rates but as projects become more automated and rely more on a few highly skilled people are system integrators still as relevant? Is it not better to employ a couple of contractors directly to work with your full-time staff?
    I guess the exception is in highly specialist areas like say Openstack where its hard to find the skilled people. For example mirantis has done well as a consultancy firm in openstack.

    Liked by 1 person

    1. Mirco Hering Post author

      Hi Neill – thanks for the comment. I tried to write up my thoughts on SIs a couple of years back:
      In short, i think you can benefit from choosing a partner who has the right experience and has skin in the game – not all partners are created equal ;-). Individual contractors can be helpful for specific skills in my experience to skill up your people – an SI partner is different as it will help you with the transformational aspects that go beyond just technical skills. Perhaps I should put an updated blog post on SIs in my backlog to explain this further.


  2. Johann

    HI Mirco, what would be your recommendation? In the past I have setup contracts with vendors to provide 2 devs and a tester to form part of the scrum team over a 6 month period.


  3. Pingback: Why Develop-Operate-Transition projects need to get the DevOps treatment | Not A Factory Anymore

  4. Pingback: Why Develop-Operate-Transition Projects Need to Get the DevOps Treatment -

  5. Pingback: 6 Questions to Test whether You are Working with your System Integrator in a DevOps way | Not A Factory Anymore

  6. kuohaotah

    Great post as always Mirco. The payment schedule example (albeit simplified here) would work very well for mature scrum teams and organizations, however for organizations that are transitioning or just starting out on an Agile journey, it’ll most likely be a contract based more on trust initially as it’s often unlikely the scrum team would define, estimate and total up story points to properly/accurately reflect functionality delivered. Having said that, if done/started up correctly, the scrum team should immediately exhibit wins in other areas (transparency, collaboration, prioritized value etc.) which could outweigh the ‘non’-delivery of functionality (if sprint goals are not met for example). Understand this catered for in your example with the ‘aim low and progressively get better’ approach (50 pts, 100 pts, etc), but how about a contract based on product owner sign-off on ‘high level sprint outcomes’ met each sprint? Ie non numerical. Have you seen that work?


    1. Mirco Hering Post author

      Absolutely – a lot of the fixed price contracts i have seen are outcome based (e.g. milestones that need to be achieved), probably not on sprint level but more on release level. Works well, but is less ‘flexible’ than the schedule provided in the post.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s