In general we consider a Fixed Priced project as something which has fixed scope and a price assigned. As more and more organisations are adopting agile for their project execution, can we have FP and AGILE go together ?
What are the risks we should consider up-front and how to mitigate those risks? Saving Changes...
Agile projects can operate efficiently under a fixed price contract, but it should be priced at the sprint level. There is too much uncertainty introduced over the course of multiple sprints to price a project for the best benefit of both client and contractor, but a single sprint is granular enough to get a sense of what is being built, price accordingly, and perform the work. Additional sprints should then be scoped and priced as an addendum to the original contract.
1 reply by Denise Canty
Aug 01, 2016 5:56 PM
At the sprint level, I am making a wag that the sprint level is based on story points.
I'd been in a situation where we scoped and priced a project on the basis of sprints and additional sprints as an addendum to the original contract.
However, in a scenario where client is upgrading and technology is just released that part of the WBS you can't add either to sprints or envisage as additional scrums.
Although these requirements are identified as mandatory but can't be implemented with existing version of technology stack.
New technology is just released to the market and not tested in house. We do not have bench marks.
Under these circumstances what is the best approach can we still work in a fixed price mode?
I'll let you know what I did ... after I hear from you. Whether best or not that is another topic for discussion. Saving Changes...
Work under fixed price for a number of sprints (estimated fixed time) would be best option. It needs to get client agree that extra cost for additional sprint if new scope or features added only but not due the team delays. Saving Changes...
Thanks everybody for your replies. What I can understand from all your responses is that we can only have a fixed price per Sprint with limited scope as mutually agreed. There is always a challenge to maintain proper agreement on cost and schedule in AGILE projects. AGILE projects are aimed at greater level of customer involvement but I think we should have a basic scope clearly laid out and agreed by both parties.
What are the risks the supplier should consider while starting such a project ? Saving Changes...
What are you dealing with for e.g. New Technology the scenario is whether in GA or Ramp up
This will help you to develop issue logs if in GA(general availability)there are always which are recorded/documented.
If you're in a situation where the technology is ramping up then situation is bleak there are issues which are not recorded or documented to fall back on.
Customer/s do not agree to anything we've not experienced in a previous project or something that has not affected others. Unknowns are not something they're NOT ready to pay for and we've to find a way to get the buy in. Saving Changes...
Fixed price and Agile can work very well together actually. Helps to set some basic context:
1. The business has to prioritize the backlog with the highest business value items delivered in order (basic agile principle)
2. The burn rate for the team can be easily estimated for a Sprint and hence the number of possible Sprints for the fixed money can also be easily estimated
3. The team's velocity can be measured and used to determine what is possible in each sprint which combined with the prioritized product backlog the rough number of Sprints can also be estimated
The product owner makes priority decisions along the way as to what should be done next with consideration for highest value, cost, and next Sprint capacity and how many possible Sprints may be left.
Following basic agile practices tell you that having a set cost number is not an issue as you constantly negotiate over what is possible to be delivered based on team capacity and time available.
This is actually how you derisk delivery - it does not add risk in and of itself.
Technology issues are of to be considered but does not affect the fundamental approach. In fact those can be handled in the same way by having a Sprint (or 2) to specifically investigate and overcome these issues which is how I handle them.
All projects have unknowns and that is where agile in fact shines - it welcomes them (that's the idea that change is welcome even late in development...another agile principle) Saving Changes...
Thanks Lawrence for your reply. Yes, agile approach adds flexibility to the way we deliver value continuously to the customer. Running an agile project definitely requires a bit of groundwork in the beginning especially team velocity measurements and release planning but it will benefit eventually.
Thanks everyone for your valuable insights. Saving Changes...