Contracts do not fix incompetence

“Contracts are the least powerful in getting people to do something. A contract does not fix incompetence.” Not my words, they come from Rajesh Mathur, but I completely agree.

Surprisingly, I often meet senior managers that view contracts as a safety mechanism. The thinking seems to be, “I’ll protect my company, but mainly myself, by contracting with a supplier to do the work. If the supplier succeeds, I get the glory. If they fail, they are legally obliged to fix the problem, and they will get the blame. Either way, I win … I mean, my company wins … we win.”

Unfortunately, it doesn’t work like that. At least nothing after the “glory” bit.

Equal opportunity failure

There is a underlying assumption that the supplier can do the work. Both the low level workers and the organisation as a whole.

Attractive and engaging sales people, nice suits, glossy brochures, high day rates, big budgets, a global presence and masses of people, do not guarantee competence. Yes, Mr Big Consultancy, I’m looking at you. A lot of senior managers believe that hiring a big consultancy will guarantee successful. My observation, based on a limited data set I admit, is that the big consultancies bring big price tags, a lot of powerpoint decks, masses of process documentation, stifling work practices and a willingness to put in more consultants (preferably cheap graduates). But not success. And of course failure brings litigation which costs more money.

Small, trendy, light weight and (supposedly) “Agile” agencies can also fail. It depends on what the work is. Light weight agencies tend to be good at light weight work. But they suffer from the Peter Principle. Just because an agency has managed to produce a cool app for you doesn’t mean you should trust them to build the new platform on which your business is planning to grow. Despite what the engaging sales person in designer jeans is telling you.

The architect says

The architect says


Actually the middle sized guys aren’t fail proof either. This sort of company will come with modest suits, modest day rates and modest experience. I trust them more than either of the above, but there is a tendency in these organisations for knowledge to go stale. The people might have been good in their day, but their day has past. So there is a good chance that you’ll just get a puzzled look when you ask them to build a new highly scalable platform in the cloud using micro services and containers.

All of that is organisational competence. You also have to worry about individual competence. Too often I’ve seen excellent people do the pre-sales and then replaced by ho-hum people when the project actually starts. Fail.

Who loses

Regardless of what the contract says, it is the client that loses most when a project fails. They wanted the deliverable and were willing to pay for it. Not getting the deliverable, and parting with the money, will have consequences.

The contract will mean blame falls on the supplier. But so what. The client has spent money and doesn’t have the deliverable. Even if the supplier manages to recover the situation there will be cost, time and quality implications.

Blame will also land within the client organisation. Somebody will have their career limited. It might not be the senior manager who commissioned the work (thus fulfilling their original hope of blameless transference of risk) but often it does.

What to do instead

The danger from all of the organisations I’ve profiled above is poor attitude. The “we can go it alone” / “we know better than you” attitude. You can get this from small agencies, middle size software companies, and giant consultancies. For me the key to success in software development is relationship. Active two way engagement. That is what real Agile is about and the thing that is most likely to lead to success. “Customer collaboration over contract negotiation” as the Agile Manifesto says.

Once you have positive engagement then take a long careful look at the supplier’s people. Would you hire them? Are they the sort of people you’d want on your team? Are you comfortable that those individuals are doing the role they’ve been assigned by the supplier? If the answer to any of these questions is “no” then tell your supplier you want new people. You’ll get away with this when the supplier is actively engaged in a collaborative relationship. (If the supplier says “no way” then you discover they are also organisationally incompetent.)

References

The quote was in a tweet by Jurgen Appelo (@jurgenappelo, 15 Dec 2014): “RT @rajeshmathur Contracts are the least powerful in getting people to do something. A contract does not fix incompetence. @duarte_vasco”

1 thought on “Contracts do not fix incompetence

  1. Steve,
    Thanks for referring to my tweet and building from it a strong argument. Impressive!
    I shared your blog post with some of my colleagues and mentioned it to the management team. The comments below are from my manager who seems to have similar yet oblique ideas:

    “Thanks for sending this through Rajesh.
    I have a similar philosophy, yet come at it from a slightly different angle. I see contracts as something you need to do in order to have recourse (when things go bad), but the issues arise when you have what is called asymmetric information. This means one side knows more about the other, there is an imbalance etc. Needless to say, it is assumed that when you are entering a contract (and vendor agreement) YOU KNOW what you want, how you want it, why you want it, who wants it, who else does it, what does it do, what else does it, what are all costs (accounting and economic e.g. transaction and opportunity costs), what are the use scenarios, what are the benefits, how does it fit the overall business strategy, how does it fit the overall departmental strategy etc. The vendor also needs to know most of this so they can ensure they are in fact delivering what you really want at the right price. So, key to getting a good outcome is not the contract itself, but clarity of purpose, awareness, information, and execution (includes resourcing, structures, financing, etc.).

    Another thing I often say is “if you have to refer to the contract, then you either have the wrong vendor, or you were not clear in your requirements”. Generally speaking, we should never have to refer to or use the contracts we sign; this is a very solid indicator that we do have the right vendor or that we are incompetent (or both). ”

    Again, thank you for the mention. I appreciate it.

Comments are closed.