Directory Image
This website uses cookies to improve user experience. By using our website you consent to all cookies in accordance with our Privacy Policy.

Why Fixed Price Projects Rarely Go Well

Author: Graham Church
by Graham Church
Posted: Sep 21, 2018

Fixed price projects sound like a good idea in theory. You have X budget for your project, you’ve found someone to hire, and you’re ready to go! Right?

Instead, the truth is that fixed price contracts are inherently riskier than other project payment arrangements.

Why are fixed price software projects appealing?

There are several reasons fixed price contracts seem appealing to clients:

  • Getting a good deal: Fixed price, you know what you’re paying, can ensure hours aren’t stretching out and budgets blowing out.

  • Trust: Where client doesn’t trust the developer and believe they may be taken advantage of if contracts are based on time & materials.

  • Risk transfer: If things go wrong in the project, the developer has to spend their own time fixing it, instead of the client "paying extra" for these hours.

(source: Fixed price without fixed specification, Magne Jørgensen Simula Research Laboratory)

Well, you know what they say about assumptions, right? Instead we’re going to investigate the possible detrimental effects of choosing fixed price vs hourly or retainer projects.

Fixed pricing can affect quality of work

Why would the quality of work differ if you’re going fixed price vs paying for time?

Well, even if developers start out with an amazing quality of work in the beginning, if they have to make decisions or change direction later on down the track - that’s going to take time.

If they’re working on a fixed price contract when their usual rate is $80/hour, then have to spend X amount of hours re-jigging the work, then it’s (likely) not going to be as good quality. Your developer can see that it’s like their real rate has decreased to $10/hour or they’re working for free.

This leads to cutting corners to get the job done - they aren’t going to waste their time for nothing.

Scope creep and Agile development are normal but nonsensical within the context of fixed price contracts

At the beginning of software projects, there will be a complete list of requirements, features, etc. that the work requires. However, as time goes along, you might decide that X feature is also necessary. Or you want to release an app on the market rather than just internally. User testing says you need X.

Agile development helps to address scope creep by continually tweaking the product with the input of both the client and the developer. When things are in this state of (manageable) flux, fixed price is impossible. You can’t just throw some extra money at that extra feature or change as it doesn’t make sense in context.

The complexities of software development and timelines

With software development, some bits are straightforward, easy, and have been done a million times. And then you have some bits that are super complex, unique, and require advanced problem solving skills and time.

While developers can often estimate which parts of your project will be which type, it isn’t an exact science. And when you’re getting a project built (as a non-developer), what might seem like an easy task on the surface could be anything but.

Sometimes you can take just any pre-fabricated door and install it in your home, sometimes you need to craft a crazy-looking door from an art sketch.

The more simple the elements that make up your project, the faster it will be completed and the less it will cost. But only your developer can gauge that.

So when is fixed price a good idea?

"A fixed bid relationship occurs when you deliver the partner a detailed project spec and they commit to complete it for a fixed price. This setup can work with smaller, highly specified projects (e.g. developing a mobile app or MVP) but is not well suited to agile development processes since larger projects tend to be defined as they progress" - Accelerance Software Outsourcing Rates 2018

Fixed pricing structures are suited to small, well-defined projects, such as:

  • A (non-functional) UI prototype

  • A small feature for an existing product with a well defined API

  • A product tweak for a product the developer has already worked on

If you’re looking for a trustworthy developer or team for your project, then come and have a chat to us at CodeFirst. We have specialists who are not only excellent coders but excellent estimators, too! Get in contact with us to learn more.
About the Author

Managing Director at UK software development company CodeFirst.

Rate this Article
Leave a Comment
Author Thumbnail
I Agree:
Comment 
Pictures
Author: Graham Church

Graham Church

Member since: Jul 08, 2018
Published articles: 1

Related Articles