Businesses have a perception about a fixed cost software project as being the best way to reduce risks of budget overruns and time overruns for the project. However here are some thoughts to consider. A fixed cost project could actually be a recipe for project failure or a way to get into notoriously high pricing.
How would a development team estimate and execute a fixed cost project? Fixed cost projects go on a very fundamental assumption that all requirements are frozen up front and that there are no technical unknowns in a project. This seldom happens with new development. Experience tells us that it is nearly impossible to spec out a requirement to the last detail where everything is visualized up front and there are going to be no parts left ambiguous. Experience also tells us that it is impossible to visualize any technical unknowns upfront in any project of decent size. When both these assumptions can seldom be right, how then is there a concept of fixed cost project existing in the market?
It turns out that the Fixed cost project is only the favorite of the customer and never of the development team. It exerts pressure on a development team to get the estimate of the project right. It exerts pressure on the development team to make sure they visualize all the technical unknowns upfront. The development team manager needs to ensure that his team is running profitably. This only means that there are large amounts of buffers added onto fixed cost projects to cover anything that we might discover on the way to execution. Who pays for this buffer? Customer of-course. If all goes as per plan for the development team, they get to keep that buffer money. They are still covered if somethings do not go as per plan.
Would the customer benefit from choosing an hourly billing model instead of fixed? It appears so. But what happens to the cases where things do not go as planned and the effort starts increasing beyond the budget. Customer loses? Looks like. But lets look again. What happens when a fixed cost project starts going off track? Yes the customer is covered with costs fixed but what does the development team do to stay profitable? You guessed it right. They take shortcuts and cut corners in the areas that dont meet the eye. Sub standard resources are deployed to patch things up. Customer might end up with a working project but do you bother to see if the code is really up to the standard? Is it maintainable in the long run? In an hourly model the development team has all the incentive to do the things right rather than to a cost.
Experience shows that it is almost impossible to get the requirements and estimate perfect each time. So there has to be a loser. That loser is eventually the customer because of substandard work that is delivered when things go wrong. The modern methodologies such as Agile advocate the concept of specifying only a part of the project and get that done before specifying the next part of the project. The only thing that is specified upfront is the vision of the project. In this model, both the development team and the customer stand to win. Customer is no more under pressure to specify everything right upfront. And development team is under no pressure to work for a cost. It will do what is needed to get the job done right.
Business heads who come from traditional industries such as machinery or automobiles etc have a hard time coming to terms with project development without fixed budgets. Top management always wants to know what the budget for an activity is so that they can calculate the ROI. Agile and such other methodologies have come into play to make lifecycle of software development better and ensure quality. Something needs to change inside the board room to accommodate this nature of software development. I am not sure what that is.
People who have given out Fixed cost projects are always familiar with the scene that happens during delivery. A legal argument about what is and what is not covered as part of the original spec. What is a change request and what is a defect. That never happens in hourly billed projects. The development team is focused on delivering whatever is rightly required for the business rather than haggle about what it is and what it is not supposed to be doing. The choice is yours.
How would a development team estimate and execute a fixed cost project? Fixed cost projects go on a very fundamental assumption that all requirements are frozen up front and that there are no technical unknowns in a project. This seldom happens with new development. Experience tells us that it is nearly impossible to spec out a requirement to the last detail where everything is visualized up front and there are going to be no parts left ambiguous. Experience also tells us that it is impossible to visualize any technical unknowns upfront in any project of decent size. When both these assumptions can seldom be right, how then is there a concept of fixed cost project existing in the market?
It turns out that the Fixed cost project is only the favorite of the customer and never of the development team. It exerts pressure on a development team to get the estimate of the project right. It exerts pressure on the development team to make sure they visualize all the technical unknowns upfront. The development team manager needs to ensure that his team is running profitably. This only means that there are large amounts of buffers added onto fixed cost projects to cover anything that we might discover on the way to execution. Who pays for this buffer? Customer of-course. If all goes as per plan for the development team, they get to keep that buffer money. They are still covered if somethings do not go as per plan.
Would the customer benefit from choosing an hourly billing model instead of fixed? It appears so. But what happens to the cases where things do not go as planned and the effort starts increasing beyond the budget. Customer loses? Looks like. But lets look again. What happens when a fixed cost project starts going off track? Yes the customer is covered with costs fixed but what does the development team do to stay profitable? You guessed it right. They take shortcuts and cut corners in the areas that dont meet the eye. Sub standard resources are deployed to patch things up. Customer might end up with a working project but do you bother to see if the code is really up to the standard? Is it maintainable in the long run? In an hourly model the development team has all the incentive to do the things right rather than to a cost.
Experience shows that it is almost impossible to get the requirements and estimate perfect each time. So there has to be a loser. That loser is eventually the customer because of substandard work that is delivered when things go wrong. The modern methodologies such as Agile advocate the concept of specifying only a part of the project and get that done before specifying the next part of the project. The only thing that is specified upfront is the vision of the project. In this model, both the development team and the customer stand to win. Customer is no more under pressure to specify everything right upfront. And development team is under no pressure to work for a cost. It will do what is needed to get the job done right.
Business heads who come from traditional industries such as machinery or automobiles etc have a hard time coming to terms with project development without fixed budgets. Top management always wants to know what the budget for an activity is so that they can calculate the ROI. Agile and such other methodologies have come into play to make lifecycle of software development better and ensure quality. Something needs to change inside the board room to accommodate this nature of software development. I am not sure what that is.
People who have given out Fixed cost projects are always familiar with the scene that happens during delivery. A legal argument about what is and what is not covered as part of the original spec. What is a change request and what is a defect. That never happens in hourly billed projects. The development team is focused on delivering whatever is rightly required for the business rather than haggle about what it is and what it is not supposed to be doing. The choice is yours.
