I have been in the IT industry for over 10 years now. I first started with freelance work and small development projects, then moved on to project management and then on to founding and leading my own software development company (Clearcode). During this time I have had the chance to work directly on more than a hundred IT projects. There were successful ones, but also ones that failed. There can be many reasons why in general IT projects fail, but I would like to share my thoughts on a different aspect which is often a factor that contributes to the failure of a project.
This aspect is the fixed bid model. Fixed bid is a term used to describe the situation when a client pays a fixed price for a fixed scope of work. Why does this model so often cause the relationship between a developer and a client to inevitably end up in at least one side (and usually both sides) not being happy with the co-operation?
Working on the Opposite Sides
Let’s start with the core of the success in any project: everyone involved needs to be on the same side working towards a common goal. In other words, the developer’s goals cannot be different than the client’s as this will put the relationship in jeopardy.
Unfortunately, this is often the first thing that is lost when you start a fixed bid project. The developer’s goal is to make the time spent on the project less than what was estimated (and billed), and the client’s to get as much done as possible. It leads to arguing over features that were assumed to be included in the scope or going through a change request procedure every time, even when a small change is requested.
It costs a lot of time, money and stress for both sides and worsens the business relationship leading each party to think that it’s really hard to work with them. In extreme cases it may lead even to terminating the project and absorbing the costs on both the client’s and developer’s side.
Predicting the Unexpected
Software development is complex. Period. Even painting a wall or a fence can bring about unexpected, extra work that needs to be done to make it right. The only difference between these examples and the situations that you face in the software development world, is that the number of things that can go wrong is somewhat limited.
In software development, the spectrum of potential issues is almost infinite, especially when it comes to creating a complex application. In such conditions, every, even the most experienced developer, will be prone to making errors and the estimate will be inaccurate.
Incentive (Not) To Excel
Allowing the developer to do his job properly is the key to excelling. This means that there needs to be enough effort put in to making things right from the architecture, code and testing perspective. It pays off significantly in the later phases of the development as well as reduces the number of bugs and regressions.
In a fixed bid project the incentive to get things right is broken due to the time constraints introduced by the fixed bid. Ongoing refactoring may be postponed, and unit and functional tests limited as soon as the developer realises that he might not complete it within budget.
These time savings usually end up incurring the technical debt that is costly to repay, causing serious problems and a lot of additional time needed in the later phases of the project.
Moving Fast
Starting the project early, making short iterations, gathering feedback and introducing improvements to the initial concept – Those options are all impossible with the fixed price project as it needs to go through a process of defining the scope very precisely (the developer wants to limit the risk), estimating it item by item and then executing it without changes or going through a change request procedure and potentially delaying the project execution.
As you can imagine, it all takes time both on the client’s side and developer’s side. The developer’s time needs to be factored into the final fixed bid (or absorbed by the developer) and eventually both sides lose. As a result, the frustration level increases.
Uncontrolled Costs?
By the end of this post, I will have addressed the key argument that is used against the hourly rate model, which is leading to the false beliefs that the fixed bid model is the solution to the problem of uncontrolled costs of projects.
When you are a product owner and you work with developers in an agile methodology with 2/3-week sprints, you become involved in the development process and you can stay on top of everything that is happening in the project, including what’s planned for the current sprint and what is expected to be delivered and when.
By adding to the granularity, per-task reporting (i.e. in JIRA or redmine) and setting the development hour’s budget per sprint or per month, you can control both the costs and the progress and gain full transparency.
So Why Chose the Hourly Rate Model?
Working with the developer on the hourly rate model ensures that:
- you are on the same team, which helps to create a better product and build a long-term relationship,
- you are saving time by starting earlier and moving forward quicker,
- you are saving money because the developer does not factor in the risk or any other additional costs in the fixed bid,
- you are gaining the transparency and control of the costs by being involved in the project planning and reviewing time sheets.
Need an experienced, full-service software development team to help you design, build and launch your project? Check out our Services to find out how we can help you with your next app or platform.
