Ashok PatraProject Manager| Tech Mahindra LtdBhubaneswar, Odisha, India
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...
nice calculation you present. But be aware, that if you don't have a setup team, that calculation is invalid: Velocity is dependent on the team and even worse: estimation has to be done by the team - and is not transferable from one team to another.
But if you have a given team with known velocity, your calculation approach for rough pre-planning is a good estimation of the budget you will need. Saving Changes...
Bret PiontekSenior Project Manager, Global eCommerce| Tacit KnowledgeOakland, Ca, United States
Jun 09, 2016 5:25 AM
Replying to Rolf Dieter Zschau
...
Hi Bret. If you fix scope then you're right. As I explained earlier, this is the approach most companies use when goint from traditional to agile. But if you go the whole path, then you will fix time. You as the client define, how much time and effort should be spent. You define the backlog, and (very important!) the priority of each item in the backlog. So you will get a maximum value (if you prioritize correctly to your values) in given time and effort. It's a different approach than traditional - for planning, controlling, purchasing. But it works perfectly for management interested in maximising value return on invenstments - even if it feels unusual at the first moment. Biggest problem when going agile is the change of approach which needs a change of mindset and often of the KPIs a company uses to rank or pay employees - since it's not the scope planning but more the value planning that is now needed. Another big pro is: After nearly every sprint (about 2 to 6 weeks usually) you can cancel investments if you're satisfied enough with the outcome. Don't try to do that in a traditional project! You will end up in a mess.
I could see that being the case if the requesting organization understands how Agile works and if the organization being contracted has the tolerance for it.
If the organization is entirely new to Agile, it'll take some time to adjust to the processes and it can be very risky to go entirely fixed price. A firm like mine relies on planned long term revenue streams, so the ability to cancel per sprint is not a sustainable model for us.
We've found it better to commit to a general theme in the SOW rather than a concrete scope. Whatever's in the backlog during the contract period is what we work on. As consultants, we work with the client to keep them within the rails of their original goal, while being flexible on the order. At the end of the contract period, the client can decide if they want to renew and we continue to refine the focus for the next period. In our case the contract periods are cost rather than time driven, although there is a general predictability between the two. Saving Changes...
A follow-up question based on the recent June 9-10 discussions (and please pardon my ignorance): In Traditional (non-Agile) approaches, the risk in a Fixed Price Contract is borne mostly by the Vendor, whereas in Agile approaches, it shifts to the Customer. Would this be a fair assessment?
I am mainly thinking about the assumptions about team velocity and the estimates about how many story points a feature takes… what if these are wrong and team produces less velocity and/or features take more story points? The risk is on the Customer, correct?
...
1 reply by Bret Piontek
Jun 10, 2016 4:54 PM
Bret Piontek
...
The risk is on the vendor or organization being contracted for the work in an Agile project. Risk is essentially the same as in a traditional project, however fixed price is less ideal for an Agile project .
The nature of an Agile project is continued delivery of value, so the priority of the backlog needs to be able to be flexible. Fixed price contracts require change control processes that can impede that flexibility and cause contention with the customer. It just doesn't align well with Agile principles.
Even if the scope is fixed in an Agile project, let's say a re-order of the backlog causes delays in analysis and getting the work ready for an iteration. If you have a contracted release date and the team couldn't deliver on time due to that change, the vendor has to eat the cost in resources until the contractual obligation is met (or they could risk being dropped and not getting their full fee).
Saving Changes...
Bret PiontekSenior Project Manager, Global eCommerce| Tacit KnowledgeOakland, Ca, United States
Jun 10, 2016 3:33 PM
Replying to Samuel Vaddi
...
A follow-up question based on the recent June 9-10 discussions (and please pardon my ignorance): In Traditional (non-Agile) approaches, the risk in a Fixed Price Contract is borne mostly by the Vendor, whereas in Agile approaches, it shifts to the Customer. Would this be a fair assessment?
I am mainly thinking about the assumptions about team velocity and the estimates about how many story points a feature takes… what if these are wrong and team produces less velocity and/or features take more story points? The risk is on the Customer, correct?
The risk is on the vendor or organization being contracted for the work in an Agile project. Risk is essentially the same as in a traditional project, however fixed price is less ideal for an Agile project .
The nature of an Agile project is continued delivery of value, so the priority of the backlog needs to be able to be flexible. Fixed price contracts require change control processes that can impede that flexibility and cause contention with the customer. It just doesn't align well with Agile principles.
Even if the scope is fixed in an Agile project, let's say a re-order of the backlog causes delays in analysis and getting the work ready for an iteration. If you have a contracted release date and the team couldn't deliver on time due to that change, the vendor has to eat the cost in resources until the contractual obligation is met (or they could risk being dropped and not getting their full fee). Saving Changes...
Lawrence CooperCreator, Lean-Agile Strategy| AdaptiveOrg Inc.Kanata, Ontario, Canada
Actually Agile and fixed price go hand in hand - you fix time and cost and negotiate on content (i.e. scope). They are in fact ideal companions. There seems to be a confusion in the thread between fixed price and agile and fixed price contracts which were not part of the question that was asked.
There are in fact no specific risks to be mitigated due to fixed price as this is a basic agile scenario.
...
1 reply by Samuel Vaddi
Jun 23, 2016 1:01 PM
Samuel Vaddi
...
Lawrence, what is Fixed Price that is not a Fixed Price Contract? I am not able to recognize the difference in the context of this discussion.
Actually Agile and fixed price go hand in hand - you fix time and cost and negotiate on content (i.e. scope). They are in fact ideal companions. There seems to be a confusion in the thread between fixed price and agile and fixed price contracts which were not part of the question that was asked.
There are in fact no specific risks to be mitigated due to fixed price as this is a basic agile scenario.
Lawrence, what is Fixed Price that is not a Fixed Price Contract? I am not able to recognize the difference in the context of this discussion. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Sure it can. The thing to take into account is what will determine the final price. You have to determine if your price is based on time, resources or deliverables. When you define it then you have to define your strategy to negotiate with your client. Saving Changes...
Denise CantyAgile Coach, Life Coach, Author, Senior Project-Program Manager| Cenden CompanyWashington, Dc, United States
I don't think that agile and fixed priced contracts work well together in "most cases" because agile scope is dynamic. It is possible to use fixed priced work packages but in general agile contracts should be flexible to allow for expected scope changes. Saving Changes...
Abel LinebergerSVP Engineering| Pathful, Inc.Asheville, Nc, United States
A significant risk would be overestimating the availability/input of the client/stakeholders. Agile relies on a more frequent and higher level interactions with the stakeholders. Early identification of who will participate in Sprint Reviews from the client side, and an agreement that failure to participate on the behalf of the client equates to Employer Delay. You may also wish to consider framing the agreement in terms of an initial 'design' sprint (with sign-off) followed by 2-3 'execution' sprints (with normal feedback loops) followed by a 'testing/acceptance/closeout' sprint as the initial schedule. Including some verbiage around framework/mockup presentations and acceptance during the design sprint may also offset potential risks. Saving Changes...
Denise CantyAgile Coach, Life Coach, Author, Senior Project-Program Manager| Cenden CompanyWashington, Dc, United States
Jan 25, 2016 10:59 AM
Replying to Eric Lamy
...
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.
At the sprint level, I am making a wag that the sprint level is based on story points. Saving Changes...
"We should be careful to get out of an experience only the wisdom that is in it - and stop there; lest we be like the cat that sits down on a hot stove-lid. She will never sit down on a hot stove-lid again, and that is well; but also she will never sit down on a cold one anymore."
