• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:

  • You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
  • You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
  • If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.

Previously on "Outsourcer vs. daily-rate contractor"

Collapse

  • XLMonkey
    replied
    Originally posted by timh
    Thanks again.

    Well, operating at the either extreme listed one's pretty much doomed to failure - but somewhere in the middle could work well. Minor changes included in the price, major changes not - or change requests in the first month free, second month reasonable, third month very pricey. That along with a well-defined initial spec (but not a highly detailed one) in order to know what a "change" is is what I'd aim for.

    I do know there's no magic number, but I wondered if anyone had real-life examples of similar scenarios?
    Yes, a couple:
    - major utility company working with a medium sized outsourcer, moving from time and materials to fixed priced contracts for development projects. The risk premium varied between 20% and 35% to transfer from a T&M to fixed price. 20% was the bottom end of what the supplier was prepared to accept in exchange for carrying the risk, 35% was generally the top end of what the customer was prepared to pay.
    - most public sector IT projects carry between 40% and 100% of project costs in the form of risk (i.e. the actual cost will be 40%-100% more than the initial business case suggests). I've been involved in quite a few negotiations to try to fix the risk premium in public sector deals - there's a certain amount of horse-trading, but in my experience it was rarely less than 15% and never more than 30%.

    ... that second example may also, in part, explain why so many public sector IT projects go over budget....;-)

    Leave a comment:


  • chicane
    replied
    Originally posted by TheFaqqer
    Shocking really, but that's how they make their money - on the change requests. As suggested earlier, if you can tie them in to only using you to fix the problems, then you're onto a winner.
    A lot of it depends on whether the OP is trying to build a business or make a quick buck.

    Whilst the big players regularly get away with tricks like those outlined here, any small software development business trying the same will soon realise that word gets around pretty quickly.

    The result being a company with one lucrative client that is eventually going to turn around and say "Enough is enough", at which time the gravy train comes to an abrupt halt.

    Leave a comment:


  • TheFaQQer
    replied
    I worked with a large "consultancy" a while back. They had won a fixed price deal with a government agency, and had really vague functional specifications.

    So the project policy was to deliver the bare minimum, regardless of how user-unfriendly it was, and charge a fortune to "fix" issues. For example, building screens where the navigation from one field to the next via the Tab key followed a random order rather than the obvious one on screen - time to fix: 10 minutes, charge to the client: 2 days. Changing the prompts on fields - time to fix: 5 minutes, charge to the client: 3 days.

    Shocking really, but that's how they make their money - on the change requests. As suggested earlier, if you can tie them in to only using you to fix the problems, then you're onto a winner.

    Leave a comment:


  • DimPrawn
    replied
    Client lock in. That's the key.

    Do the work, making it very hard for them to go elsewhere when they need support, enhancements, changes, fixes outside of warranty.

    Then charge the absolute earth. I'm talking £1000+ per day min.

    Leave a comment:


  • scooby
    replied
    Originally posted by DimPrawn
    A lot of these outsource, fixed price merchants rely on very expensive (lucrative) support contracts and high value repeat business.

    So they take on the risk at a std price and when they get stitched by the client for requirements changes, they charge the earth on subsequent projects and support contracts going foreward.
    too true!!!!!!! they get the business, then make the money once under the table!

    Leave a comment:


  • scooby
    replied
    depends on the outsource co... the one i used to work for had internal day rates which where charge to projects. the projects then charged service management, SM then added a % and billed the client.

    as someone has already said, fix price throws this out of the window!

    Leave a comment:


  • DimPrawn
    replied
    A lot of these outsource, fixed price merchants rely on very expensive (lucrative) support contracts and high value repeat business.

    So they take on the risk at a std price and when they get stitched by the client for requirements changes, they charge the earth on subsequent projects and support contracts going foreward.

    Over the long term you can make good money like this if you have big balls.

    Leave a comment:


  • Ardesco
    replied
    Alas i have no idea. Bear in mind that the cost is going to change depending on specification as well. Thier interpretation of a small web project may not be the same as yours.

    For example I worked with a company a few years back that coded an in-house bespoke credit card payments system. The system dealt with refunds by setting a field in the DB from P (Payment) to R (Refund) as they only ever refunded in full. The program got into UAT and the accounts department decided that at some point in the future they may not refund the whole amount, but just part of the amount.

    This was never in the original design and was obviously quite a substantial rewrite to the code and the database structure, however the accounts department couldn't understand why it would take so long to implement because as far as they were concerned it was a minor change.

    Remember mentality like this when speccing out the responsibilities, in the first month you could end up with 3 complete code rewrites because they change the focus of the program so much.

    Leave a comment:


  • timh
    replied
    Thanks again.

    Well, operating at the either extreme listed one's pretty much doomed to failure - but somewhere in the middle could work well. Minor changes included in the price, major changes not - or change requests in the first month free, second month reasonable, third month very pricey. That along with a well-defined initial spec (but not a highly detailed one) in order to know what a "change" is is what I'd aim for.

    I do know there's no magic number, but I wondered if anyone had real-life examples of similar scenarios?

    Leave a comment:


  • chicane
    replied
    Originally posted by timh
    what a typical client would want to pay for such a service
    The amount that the client is willing to pay depends on the amount of risk that they can offset to you.

    In terms of the amount of risk, it's going to lie somewhere between two extremes:

    1) You will implement any change the client asks for during the course of the project, regardless of the original objectives or requirements and regardless of time/cost overruns. The client may have started by asking for an e-commerce site but may end up with software to control the Space Shuttle.

    2) You will spec out the project at the beginning in extreme detail. Anything requested by the client that you deem to be outside the original specification will be chargable.

    There are no magic numbers here - it all boils down to the individual client and the value that you're willing to offer them and the risk that you're willing to transfer from them. Your best bet is to sit down with them, talk about the project, talk about the risks they're facing and how you can help deal with those risks, negotiate a price and get the contracts signed.

    I appreciate that this once again fails to answer your question. But that could be because software development businesses have been agonising over these issues for the last 40 years with no clear answers - only further questions.
    Last edited by chicane; 21 June 2007, 14:08.

    Leave a comment:


  • timh
    replied
    Thanks for the replies; I have thought about the above already, and am assuming there would have to be a good 30%+ extra factored in for changes, and careful management with multiple stages of signoff etc. Some clients seem to actually like having penalties for changes in their outsource contracts because it forces their employees to make better decisions earlier - usually the people who decide on the contracts are not the marketing/management monkeys who will try to constantly change their minds late in the process.

    My question is more about what a typical client would want to pay for such a service, in order for me to have some idea whether it's actually worth doing of if it's too much of a pain in the arse. I don't mind it being a huge stressful hassle, as long as the potential profit is big enough; I'm pretty confident in my ability to deal with the associated client nonsense and make it work.

    (Ardesco: Assume it's a small, specialised, high-quality UK outsourcing co. I'm not particularly interested in moving work abroad.)
    Last edited by timh; 21 June 2007, 13:58.

    Leave a comment:


  • chicane
    replied
    This is a difficult question to answer directly, because the whole "fixed-price" concept for web projects is one massive can of worms.

    Fixed price solutions require extremely good organisation, planning and discipline by both supplier and customer. Both parties need to have an extremely good understanding of what's going to be delivered by the project - and in reality neither party is in a position at the outset to understand this.

    You can either specify the deliverables in terms of objectives or a detailed technical specification - but you can be sure that in either scenario the customer will change their mind several times along the way, and somebody has to pick up the bill for this.

    There are a number of ways to deal with this (change budgets spring to mind), but they all boil down to the fact that somebody, somehow, has to pay for the changes.

    If you foot the bill, you lose out. If the customer foots the bill, then they have no longer transferred the risk to you, hence there is no benefit in them paying you more to do so.

    I think you need to give more thought to exactly what you're going to provide for the fixed price.

    Leave a comment:


  • Ardesco
    replied
    How long is a peice of string?

    All depends on how good the company you outsource is, how big they are and what sort of standard of contractors you get.

    I'm sure you could send it out to China for peanuts but you may get a pile of poo back.

    Leave a comment:


  • timh
    started a topic Outsourcer vs. daily-rate contractor

    Outsourcer vs. daily-rate contractor

    'Lo,

    Does anyone have ballpark figures for how much extra a company will pay to pass on much of the risk associated with a project (outsourcing for a fixed rate) rather than just pulling in a bunch of contractors?

    (If you need an example project, let's say a small-medium web project taking 2-3 developers 2-3 months.. Cost to contract the developers directly would be 50-70K).

Working...
X