Many in the IT industry are of the opinion that Agility and Fixed Costs are two extremes and can not go together. In an ideal scenario, they can not go together if we go by their true difinitions. Fixed Cost safeguards businesses, whereas, Agility helps the development team in safeguarding the unknowns and risks. Typically, fixed costs are associated with the waterfall approach, and agility means that the team has to work in T&M mode to manage the uncertainties and change in direction.
Estimating and adding a fixed price at the beginning of a reasonably large project is a big challenge. The following are some of the major reasons:
- Buyers and suppliers do not know each other, i.e. lack of an existing trust relationship
- Project is under a major time pressure, so there is no time for in-depth upfront planning
- Requirements evolve with time
- Project requires the use of unknown technologies
- Fixed-Price offers from multiple vendors are too different, so they can not really be compared
Fixed price with fixed scope does not help in a ‘win-win’ situation during the phase of Product Development in many cases since defining every details of the scope is not feasible at the start of the contract and few things are bound to change. Every suggestion for improvement from customers and the development team often ends in a scope and cost debate, which takes up a lot of time and focus.
So, how can we have agility in Fixed Cost? There are a few techniques to do that. One of them is by using the concept “Fixed Price, But Variable Scope”, which means to come up with a plan that says, “We have $X to spend and we need 3 monthly releases, (July, August and September). Stakeholders and team will collaborate to prioritise and include the must have features to go live within the defined timelines of 3 months – which also means that we might not complete the whole product backlog”
By the time team has spent 3 months on developing something tangible, stakeholders must identify the next chunk of scope to be implemented in the next time frame for $Y. This way the risk of “Fixed Cost” is broken down in an agile manner.
Next level is to start with a couple of sprints to understand the depth of the landscape, system, requirements, unknown parameters, and then modify the project plan and the cost accordingly.
Lastly, instead of one number, come up with a range of costs, along with clear assumptions and risks. The lower number states that team can not make it any faster. Upper Bound means that the project can cost up to this amount, the team will try to keep the costs lower but it may go to upper limit if the assumptions / risks are not mitigated.