≡ Menu
Pawel Brodzinski on Software Project Management

Are Fixed-Price Projects Bad?

I’ve read recently a discussion about agile approach versus fixed-price projects. Several comments from the discussion:

Doing a project on fixed-price/fixed-time basis since it’s unfavorable for a client.

If client insisted on fixed-price I wouldn’t sign the contract.

As long as there are companies doing crappy [fixed-price] contracts clients will insist on fixed-everything.

We believe that fixed bids are a bad idea when it comes to software.

Whew, that was fun to read. I mean I love these kinds of strong opinions which omit plethora of real-life situations their authors (fortunately) have never faced.

I wrote pretty long argument why these statements aren’t very wise (not to say some of them are plain stupid) but I deleted it. Basically I have only one conclusion: being orthodox is always a bad thing.

in: project management, software business

10 comments… add one

  • Marcin Niebudek October 29, 2009, 12:58 am

    :-) I still wonder why the emphasis on the "fixed-price contracts" is set on "price".

    These discussions often rise in the agile community, but for me there is nothing wrong in fixing price or even time (in terms of deadlines). In fact I believe it's quite helpful.

    Most of the contracts I've been working with were fixed-price ones. Some of the projects where successful some of them were not and the contract itself had little to do with it, but the way it was managed did a huge difference.

    What I don't like in those contracts is the fixed list of requirements, which in agile context is a huge obstacle to sustaining the "change welcoming" mentality.

    I recently wrote a paper about it called "Agile Team Meets a Fixed Price Contract", so if anybody would be interested in reading it I may put a link later on in comments (didn't want to hijack the thread here).

    So putting it short – I agree with you Pawel about the orthodoxy.

    Regards,
    Marcin

  • Pawel Brodzinski October 29, 2009, 1:39 am

    About embracing change you write there's one sentence from Alistair Cockburn which hits the nail:

    "I’m not happy encouraging people to just change stuff all the time – it’s more efficient to think for a while and try to make good decisions early – the world will supply enough change requests without us adding to the list by not thinking."

    And fixed scope is another candidate to write about here. Yes, I agree that's the toughest one of the iron triangle.

  • Meade October 29, 2009, 5:57 am

    If a person wants a hamburger, sell them a hamburger…with the historic poor delivery from IT why would WE think the client would be comfortable with an open-ended 'lets see what gets delivered' contract…when you order a computer do you have to worry about only parts of it getting delivered for the agreed to price? SOME software development is R&D – but at this stage there should be enough knowledge to accurately deliver certain building blocks confidently at a fixed cost…how many NEW AR systems get delivered and never work? How many simple web sites projects fail? Before we start criticizing the client I think we need to be real sure about ourselves.

  • Pawel Brodzinski October 29, 2009, 6:34 am

    Meade,

    If a client wants a hamburger we sure should sell them one. Usually they want just something to eat. Something they like. The question is what would they consider as tasteful at the moment and what would it be when you're ready to serve.

    The problem isn't in open-ended approach to define project scope. We all collectively suck at defining requirements. That's why we so often end up with clients defining something other than they want and vendors delivering something other than both.

  • Meade October 29, 2009, 6:50 am

    So, if the development group can't define what the client wants they should start to develop something until they get close – while the client is paying for the attempts? I'm not anti-agile, I very pro the Manifesto – but think that people use Agile as a crutch to get paid to do something without putting much (or any) pre-thought into it…the client should pay more $ for a IT group that understands them but should they pay in the education of an IT group that doesn't understand them? or should that cost be partially absorbed by the IT group and seen as a cost for potential future business..?

  • Pawel Brodzinski October 29, 2009, 7:07 am

    Meade,

    Of course agile shouldn't be treated as an excuse for not knowing exactly what to do and staring development anyway.

    I'm totally with you at the point you've raised which is treating a part of analysis process as an investment vendor makes to better understand what should be done. This is actually the part which is appears astonishingly often for transferring the cost of all bad decisions, made bilaterally, only to one side – the customer.

    On the other hand I'd be far from generalizing to the point where we set it as the only source of the problem. For each example of vendor not putting enough attention to proper analysis and design I can give another of client being unable to say what the want. And the other way around.

    Although I work on vendor side I couldn't be farther from blaming clients for every problem. I have worked however with customers which have almost always using "feed me and guess what I'd like because I'm not going to tell you" approach.

    And no, I wasn't anywhere close to advice anyone to resign from signing these contracts.

  • Marcin Niebudek October 29, 2009, 10:25 am

    @Meade I cannot agree with one thing you say. You say that R&D is only a small part for each team, and you don't want to pay for education. From my experience most of the projects made on fixed-price contract are something new in terms of problem domain. During the last 10 years I haven't worked on any two projects that had the same problem domain.

    That's why it's always so hard to do 100% accurate requirements analysis up front. I don't believe it's possible in more than 50%-60%.

    However I do think that T&M contracts are lacking the boundaries and focus. We (vendors) just do, without incentive to deliver value. Work done, work paid so to speak.

    When we face a fixed price contact we actually pay more attention to deliver just what is needed and when it's needed. So I prefer to work with external clients based on such boundaries like some release dates, budget, scope (in terms of amount of work to be done).

  • Meade October 30, 2009, 8:36 am

    @Marcin – there has to be at least one thing you agree with…(kidding). In regards to my R&D statement, its in relation to new technologies – building a web site with Php/MySQL or some common combination should not be R&D like a this point – not for a seasoned company. Look at it from the client perspective, why should they pay for a software company to learn their trade? You don't pay an electrician to learn the basics every time they come to your house to put in a new light fixture? There's no such thing as 100% accurate anything, but the walking in the dark with our eyes closed times need to come to an end, we need to stop focusing on what's easier for us and more on quality and what's best for the client.

  • Harvey Kandola November 9, 2009, 5:14 am

    Fixed price projects and "minding the gap" between "what they asked for" and "what they actually need"…

    http://blogs.countersoft.com/index.php/2009/11/mind-the-gap/

  • Bimal July 9, 2013, 9:30 pm

    Request you to send me the link of “Agile Team Meets a Fixed Price Contract” on my email.

Leave a Comment