Ask HN: Alternatives to Time and Material Contracts | Hacker News Reader

Ask HN: Alternatives to Time and Material Contracts

2 pointsDishyDev3 comments

I work in UK Software/IT Consulting and I've seen that the vast majority of deals I'm involved with are Time and Materials with fixed rate-cards. I rarely see outcome or goal based, which feels very limiting. Especially as you trade up the technology stack (Windows VM management compared to Kubernetes) where fewer experienced engineers can deliver more.

I've seen Time and Materials contracts driving bad body-shopping behaviours, as profit is driven by head count. And junior resources have better profit margins than seniors.

How do other more innovative consultancy businesses handle this issue? Is T&M just a reality of consulting?

I'd love to try and offer something more outcome based, where an organisation can profit from their expertise. But the first question on any proposal seems to be what is your hourly rate.

View on HN

A lot of IT consulting may involve writing or configuring software and systems. And before that, requirements analysis. So it's not something that you can estimate realistically.

And neither the consultants nor the hiring company can afford to really get the raw end of a deal.

If you think you have information or skills with Windows VMs or whatever that is very valuable then you can certainly try offering some fixed fee for some particular outcome.

It is likely the real requirements will not be available until a qualified person spends a significant amount of time doing that analysis. So the desired outcome will change after the contract is signed. So will the estimated amount of effort and you may also find that you don't even necessarily have the staff to handle the requirement.

I think the amount of effort to successfully deploy projects, unless they are extremely routine, often does not leave as much room for profit as you might think. Especially if increased hours do not add to the fee charged. It becomes a conflict of interest where one side wants to squeeze as much work out as possible and the other wants to do as little as possible. So having a useful outcome can be a casualty of that.

Really well put on the risks and how outcome based projects aren't necessarily better aligned for good outcomes.

The best company I worked with did a multi-drop "agile" contract where there were several incremental prototypes and product releases with feedback and tuning the requirements to ensure we got what we needed in the end. That felt far more aligned and how I'd prefer to work but it took a lot of trust and a long relationship with the vendor.

I feel that it's almost always necessary to have more than one delivery at different stages otherwise some important feature or bug fix doesn't make it in.

You could say each increment is a fixed partial fee or milestone but that doesn't work unless there is adequate requirements analysis at the start, and they are small increments that can be determined dynamically and/or in a highly prioritized way.

And also each increment has to be the equivalent of billing for that block of time anyway.

Reply on news.ycombinator.com