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:
https://notafactoryanymore.com/2015/01/30/working-with-sis-in-a-devopsagile-delivery-model/
Agile Reporting at the enterprise level (Part 2) – Measuring Productivity
Not A Factory Anymore 
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.
LikeLiked by 1 person
Hi Neill – thanks for the comment. I tried to write up my thoughts on SIs a couple of years back: http://wp.me/p4NBE7-1G
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.
LikeLike
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.
LikeLike
Pingback: Why Develop-Operate-Transition projects need to get the DevOps treatment | Not A Factory Anymore
Pingback: Why Develop-Operate-Transition Projects Need to Get the DevOps Treatment -
Pingback: 6 Questions to Test whether You are Working with your System Integrator in a DevOps way | Not A Factory Anymore
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?
LikeLike
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.
LikeLike
Hi Mirco,
With regards to story points-based pricing, have you agile teams experienced clients who were very strict on and would challenge every story point estimation as well as request more features within the same estimated user story? How did you manage those events?
LikeLike
To be honest that scenario has happened only rarely and requires a bit of coaching from an experienced Agile coach. In the worst case you would have to go back to acceptance criteria and enforce the Agile process, but mostly it can be solved by discussing the reasons behind the requests and looking for a joint response to it.
LikeLike
Thanks for the response. In addition, if the team was not able to get acceptance from product owner for some user stories then the delivered points will be less than the contracted SP. In this case, either (1) the client will not pay for the story points for “undelivered” use stories, or (2) adjust the sprints (increase target velocity or add new sprint) to deliver those user stories. On these options, the SI will shoulder the additional cost of delivery. How do you handle this?
LikeLike
That is the risk of delivery just like it was with fixed price contracts in the past. Key is to have clear acceptance criteria per story so that the expectations are managed well. At the end of the day, most people are well intentioned. And as in the example, you can catch-up later if you improve your delivery performance.
LikeLike