Software Development Hourly or Fixed Bid

time and materials software development

Article written by Brett Miller

At first consideration, software development fixed-bid pricing seems to have some real cost control benefits because in theory, it forces both the development vendor and stakeholders to carefully scope out the project in advance. In a perfect world, those things might be true … but this isn’t a perfect world is it?

Challenges in Estimating Software Projects

  • Estimating Development Effort; In order to create an accurate fixed bid for a software development project, the vendor and client must spend a tremendous amount of time communicating requirements.  The time required to create an accurate estimate might outweigh the potential benefit of landing the project.  Would you want to spend 80 non-billable hours estimating a project you might not get?
  • Project Requirements; Advanced planning attempts to predict every project requirement before they might be known… however project requirements frequently do change which causes the price to change.  This can create some conflict between vendor and client (determining if functionality was in original project scope).
  • Eliminating Risk; There is no possible way to fully eliminate risk in custom software development.  But fixed-bid pricing attempts to shift the risk to the development company who, in turn, is forced to provide themself with overrun protection.  Therefore, all fixed bid pricing includes coverage for additional cost contingencies … even if the vendor doesn’t end up needing them. Logically speaking that means all fixed-bid pricing increases your costs rather than saving you money as you might have thought.

Software Development Fixed Bid Model

Fixed-bid pricing works well for certain business functions like payroll processing or running a marketing campaign which are both repetitive and predictive in nature.  Alternatively, application development needs to follow a project management lifecycle … from design, through cycles of development and finally implementation. Each phase has its own risks and is dependent on the success of all preceding phases (among many other external factors).  In fixed bid applications, project success falls on the accuracy and completeness of the original project specifications.

In general, custom software development projects are more likely to succeed if two simple predictors are addressed up front.  First, the stakeholders are in total agreement on what it wants to accomplish; and second, project scope is structured, planned, and directed by knowledgeable and experienced project managers.  Unfortunately, fixed-bid pricing effectively reduces much needed flexibility.  And that means that even the best project managers must often choose between “well executed functionality” and “finish it within the budget” motivators.

Software Development Hourly Model

Design, Specification, and Functional Fluidity; allows for changing stakeholder needs and/or market contingencies.

Functionality of Project Outcome; allows preferential treatment of overall project outcome and functionality against simply meeting budgetary constraints.

Costs Actually Reduced; Time and material pricing means extra costs are electives … to be paid only if and when they occur  (and are authorized) … whereas in fixed-bid pricing these extra charges are padded whether they are needed or not.

 

Do me a huge favor (please) and click:
 

No related posts.

3 Responses to “Software Development Hourly or Fixed Bid”

  1. A great distillation of the different approaches to development. Having talked about similar aspects of custom software development your points regarding the different risks to both parties is defiantly something to keep in mind.

Leave a Reply

*

Contact Us

Client Feedback

"Your software developers are superb and represents your company well in so many ways, they are lightning fast at grasping the concepts that were needed to pull this off." - Client

"It's clear from your developer's searching questions and intelligent suggestions that they really understand the nuances of our custom software project. They aren't afraid to make suggestions for better ways to do things. I can certainly tell that they want to 'own' this dev project." - Client