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...
As others have said, it is possible but only if your client fully accepts the concept of sprints and other concepts in Agile. If they are inflexible they will agree to Agile in theory but in practice the project will turn into a waterfall methodology.
I've personally been in this situation where clients want a complete product at the end of three months at a fixed price and are unwilling to reduce scope or to plan in terms of sprints. For example, we had demos every two weeks for the client but due to poor planning at most of those demos we did not have a working product.
Clients need to buy into Agile and need to accept to be flexible to reduce scope and to play an active role in sprint planning. Too often "fixed price" turns into "increase scope and burn out the workers to make the deadline". It's not good for your project and it's not good for your client. Saving Changes...
I personally believe, FP is possible like Lawrence explains. But as RudolfpPoints out it requires a fundamentally changed mindset at client and contractor - and a really strong Product Owner at client side that prioritizes backlog according to business needs/value - and accepts some technical stuff too. The Magic Triangle is used differently than in traditional FP Projects: traditionally scope and Price are fixed. In Agile time and Price are fixed. Proper backlog prioritization ensures Maximum Business value outcome for the Price and time invested. This Change in Approach is very strange to purchasing and many Clients - as well as to some of our own Managers / sales staff. But it can work if you build trust at the very beginning (so start with small Projects, where you can prove the Approach works) Saving Changes...
First of all, I am still in process of fully understanding Agile… so please hear me out and help me out with clarifying my understanding.
Isn’t SCOPE in Waterfall = BACKLOG in Agile? And, in a FIXED PRICE contract situation, shouldn’t the scope/backlog be FIXED also? Use Agile to mix-and-match and deliver in a flexible fashion, but the overall STUFF you deliver should be fixed in advance.
In other words, whether or not you can go a FIXED contract depends on whether the STUFF expected of the vendor is FIXED and not on the methodology being used. Is that correct? Where am I going wrong? Saving Changes...
you describe very well the dilemma every one encounters when changing from traditional to agile approach. I had the same thoughts last year until an agile evangelist told me the story of using Magic triangle differently - and that solved the dilemma for me. Since agile is all about maximizing business value at delivery Point - not planning/starting point of a project, you cannot fix scope. Every scope fixing will prevent, you hit the maximum. You have to reprioritize backlog items during a (sufficiently Long) Project. If you set fixed price per sprint (as someone stated at start of this discussion), you are better off, but also during a sprint it's common to reprioritize in a backlog refinement session. You could handle that with change requests like in traditional projects - but that formalism is seldom appreciated in agile Environments.
So the fixed suff is: you get a running System at the end of the project that will provide you a maximum benefit for your Business for time and effort spent. And you as a Client are the one, that is in control of the functionality you get - for the whole Project - and you can Change your mind nearly up to Project closure. What else do you want? :-) Saving Changes...
To fix the price requires for scope or time to also be fixed. While we are used to fixing scope, you can certainly fix the time.
The advantage of fixing time, rather than scope, is there are less associated risks. You don't need to add large contingency or management reserves when pricing the work. Saving Changes...
I see that from the vendor's standpoint, fixed pricing at Sprint level (i.e. fixed time) is very low risk. However, if I am the customer, isn't it high risk for me, as far as functionality benefit for a given cost? I know I will be spending only a fixed amount, but there is no guarantee about what I will get for that amount, because the scope is not fixed? Saving Changes...
It is, Samuel, if your backlog is volatile. If the client goes into to the fixed price, fixed time with a known and prioritized backlog, they are getting as much scope as possible in a given sprint. Saving Changes...
jeff heathProject Portfolio Management Consultant| Northop-GrummanBowie, Md, United States
Here's a scenario for you Ashok....Let's say an Agency wants a specific project delivered in an Agile Scrum. As Lawrence stated above, that Agency would have to produce the product roadmap and build & prioritize the product backlog. Next, the Agency would estimate how many story points for the entire product backlog. From there, the agency determines how many releases do they want in the year, and how long each sprint will be. Now, the Agency makes assumption as to how many members are on the sprint team and how many teams will be needed. Add in an avg standard planning rate for the team. From the data above the Agency should be able to arrive at an estimated project cost, cost/story, and velocity that they can use to negotiate a fixed price effort.
Agency desires 10 days sprints and wants releases Quarterly, This means about 6 sprints per release. Total of 24 sprints + 1 sprint zero = 25 sprints for the year.
Agency estimates Product backlog = 1000 story pts
Agency estimates velocity = Backlog/Total sprints = 1000/25 = 40
Agency wants one team, composed of 7 members, avg cost per member is $100
Cost/sprint = 80*7*100 = $56,000
Cost/Story = Cost/Sprint/Velocity = $1400
Total Cost = $1400*1000 = $1,400,000
Agency has a starting point for negotiating a FFP effort with a supplier. Saving Changes...
Bret PiontekSenior Project Manager, Global eCommerce| Tacit KnowledgeOakland, Ca, United States
Fixed Price contracts are not ideal for Agile projects because the terms of success are focused on delivering value to the customer rather than measuring a project's success against schedule and budget.
A customer may be willing to go over budget or delay release in order to deliver high value to their users. Agile projects by their nature are flexible in their scope as market conditions require businesses to adapt their strategy. Agile also focuses on reducing waste and prioritizing customer relationships over contracts.
In a fixed price contract, the company contracted to do the work assumes all of the financial risk. If a project takes longer because of a change in scope, the profit margin can be severely impacted. Fixed price contracts usually require rigorous and bureaucratic change control processes that can slow things down and strain relationships with the customer. This doesn't align well with Agile values.
Agile projects are better suited for contracts that are more flexible in nature like Cost Plus Incentive or some other arrangement where the priority of the scope can be altered to the customer's business need while still delivering value in the form of working software. Saving Changes...
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.
...
1 reply by Bret Piontek
Jun 09, 2016 9:56 AM
Bret Piontek
...
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.
