Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Risk Management, Scope Management
Can AGILE projects run on a Fixed priced mode? What all concerns or risks one should consider before taking over such a project ?

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?
Sort By:
Page: 1 2 3 4 next>

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
Denise Canty
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.

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.

great question! good replies....thanks!

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 ?

I think the major risk would be the team delay which cause to over cost and client may not willing to pay the extra sprints required.

Risks :
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.

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)

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.
Page: 1 2 3 4 next>  

Please login or join to reply

Content ID:

"My sole inspiration is a telephone call from a producer."

- Cole Porter