Renewing a contract on a deliverables-basis rather than time and materials/day rate?

[malvolio]

I am applying or BA contracts and I have seen a few based on deliverables.

I am assuming most on this thread are talking about software delivery where challenges like dependency on others applies.

Presumably for a BA it would be more along the lines of the production of a requirements spec which might not be subject to the same kind of problems as software deliverables? Has anyone heard of BA's successully taking on fixed price contracts?

My latest deliverables were a high level Service Design for an outsourcing bid*, a detailed Service Design, an implementation approach and a range of technical proposals for things like a CMDB and a Service Desk classification matrix** plus a training plan for their staff. So not all about software, or even tin, but quite a lot of business analysis to define the requirement properly before getting into the architectural stuff.




* Dependency 1 - did they win the bid based on my design? If not I had a price point defined in case.

** Dependency 2 - These were on a call off basis, allowing for their teams to define their own if they could (or if they already existed)

[hgllgh]

I am applying or BA contracts and I have seen a few based on deliverables.

I am assuming most on this thread are talking about software delivery where challenges like dependency on others applies.

Presumably for a BA it would be more along the lines of the production of a requirements spec which might not be subject to the same kind of problems as software deliverables? Has anyone heard of BA's successully taking on fixed price contracts?

[David71]

Worked a couple of projects on deliverables. I think Malvolio covered most things. But here's my pennie's worth.

Pricing: I guesstimated how many days each task would take then multiplied by my 'indicative' day rate (not disclosed this to the client). My estimations were based on experience plus I'd seen the clients schedule and how long they had assigned to each task so used htat as a guide as well

Timings: If you're waiting due to delays and you take longer to finish each deliverable then your 'indicate' day rate goes down. I was waiting for weeks for others to finish their tasks so I could start mine....annoying but if you finish early then bonus!

Task cancelation: get something written down about what happens if you get to 90% completion on a deliverable then the client decides they don't need it. Happened to me on one project a lot but I just had a meeting with the client and agreed how much %age I'd done and billed accordingly.

I really like working on deliverables as I find it gives much more 'freedom' to how and when you work and if you get stuff done in a shorter time than you first estimated then you still get paid what you quoted.

[jamesbrown]

Yes, I do this all the time. I don't have much to add to Mal's excellent post.

The hardest thing is pricing, even when you understand the work required, especially when the tasks are not totally self-contained and depend on client progress in other areas. It is very hard to find that sweet spot where it's commercially viable for the client and minimises risk and maximises profit for you. That only comes with experience. Regardless, some serious effort in estimating will often pay for itself, even though it costs you the time to do the estimation and there are no guarantees you will get the work. I have had several fixed price gigs where I've lost money, but some where I've made a ludicrous profit and, ideally, you don't want either of those outcomes in the long run.

[northernladuk]

My first thought here is does the actual work lend itself to a deliverables approach. You need to pick the right option to suit the work, not for tax or IR35 reasons. Whether it's day rate or deliverable should really be dictated by the work and use the best option to deliver. If you are part of a big project, much of it is out of your hands and it's going to be nigh on impossible to define and deliver to the agree SoW then it's just not going to work. If you can own a complete piece of work and have the authority to deliver then fine.

You could think about a halfway house where you are paid monthly on agreed deliverables that month and agree the next month and so on. Not quite bum on seat but also not quite total delivery as you might not be able to fully achieve that.

But either way, look at the work and use the best model for the work, not IR35.

[PerfectStorm]

Thank you Mal. I should point out that there is an agency in the middle of all of this so it will be them that I'm working with on the contractual terms rather than the end client in its entirety, but all your advice is useful, thank you.

[malvolio]

Tricky one. Key points to consider:

Pricing. You have to set a total price without knowing what it will cost you in time and (possibly) materials. You know the deliverables, so work out their likely time to produce them, input costs and dependencies. That should give you an overall plan. You also know how many days, so multiply that by an acceptable day rate. Add other expenses at cost, such travel, licences, hardware, whatever. Include any potential or planned sub-contracting costs of course.

Margin. You're there to make a profit so add 40% to the total. That's the end price to the client. How to break that down over the life of the project is up to you to agree with them; I used a percentage but I was delivering roughly equal items without any tin and wires.

Staging points. Are there points where you can charge for work done to date; conventionally that is the delivery of agreed individual deliverable(s)

Quality and Acceptance Criteria. You need to agree these up front so you are clear on what you have to deliver a each stage, including testing processes or demonstrable success points. These are important...

Completion. Define the overall end point - for example a fully operable website with supporting infrastructure and services. You can also have an agreed sum that is only to be paid at this point.

IPR. Who owns the end product and who can use it. Can the client sell it on without paying extra, for example.

Change management. Even Agile shops need to control contractual changes and requirements updates.

Payment Terms. When do you get paid for each point in the project. Don't be surprised if there is at least 60 days between invoice and payment, but you still have to pay the mortgage.

There are templates out there (I think IPSE still have some good ones) for the contract, schedule of work, contractual terms and the rest (including the usual guff about confidentiality, liability and Force Majeure). You will be working with their procurement team who will have their own rules and requirements. While they will have a process for small suppliers, you will need to meet their needs and that can get complicated if they start asking about capitalisation and the like.

Those are the the things I'd considered in similar gigs. They work well as long as you hit your targets and keep the client up to date regularly and consistently, including any risk facts, predicted or actual. They are not buying surprises!

Keep us posted. Lessons learned are always useful!

[PerfectStorm]

Bit of a new one. I'm talking to an old client about renewing a contract from a while ago that was time and materials Outside (so, a day rate in other words) to a deliverables-based one (still Outside), which I assume is going to be fixed price in some way (discussions are yet to be had).

Has anyone done this and what to be aware of? How did you arrive by a price? How did it play out in the end?

Not seen any info on this online so would value your helpful experiences, thank you.