Can Fixed Cost And Agility Go Together?

Himanshu Varshney

10 Jul 2017

Can Fixed Cost And Agility Go Together

Many in the IT industry are of the opinion that Fixed Cost and Agility are two extremes and cannot go together. In an ideal scenario, they cannot go together if we go by their true definitions.

 

What is the difference?

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:

 

 

Fixed price with a fixed scope does not help in a ‘win-win’ situation during the phase of Product Development.  This is because defining every detail of the scope is not feasible at the start of the contract.  Many things are bound to change in the process.

 

 

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.

The Best Approach

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. This includes understanding 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 a 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.


Have a question?

Need Technology advice?

Connect

+1 669 253 9011

contact@hashedin.com

facebook twitter linkedIn youtube