September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
There is not a "best way". There is the way that best fits for your initiative. The key is to understand what agile really is. Some people think that Scrum is a synonim of agile. That is not true.
The best way to manage costs in an agile approach is to simply use a parametric approach.
At it's simplest, if you have a fixed duration - your iteration - and fixed resources - Scrum team - then your only variable becomes the scope - how many iterations.
I don't know how you could do firm fixed price. That assumes you know everything about the project up front, and Agile fits best in high change environments. Time and materials is my preferrence as a contractor because I know I will get paid for all my work, but customers usually don't want to write a blank check.
In Agile projects what is the best way to manage cost?: In general, the scope of agile project is uncertaint and unclear at the beginning so I think the suitable way to manage cost is to manage cost with each release in association with product roadmap. The shorter length of release, the more effective and accurate at which the cost will be managed. I also want to know if there is a best way existed.
Which one is high risk fixed bid or T&M?: It is depend on you are a requesting organization (buyer) or performing organization (seller). For fixed price contract, the risk is high for seller. For T&M contract, the risk is distributed to both buyer and seller.
As mentioned a few times before, agile approach and way of work is not connected with the fixed deadline or costs.
Anyway we live in the world where cost and term is always a top spot on the contract for the management.
So basicaly the best way, at least for my projects, is to make a WBS as detailed as possible and let architects and senior developers make an expert estimation. Then set an appropriate buffer according to not-so-described work.
Still better clear and transparent project plan, than explaining open deadline to some conservative sponsor.
I believe this is a fair attitude for all stakeholders.
This is overly simplistic, but if you are delivering regular product increments, then your stakeholders can decide if your project deserves more funding. That's how the budget is managed. Really, this is how I've reduced risk in many long, predictive projects: we use various proofs of concept and regular stage gates to ensure we're funding the right projects at the appropriate levels, and we have a change control process if the scope needs to be adjusted. In an Agile environment, these kinds of inspections and changes are expected and ingrained into the culture and process.
Scope should be fixed and any changes done should be within the scope. Identify resource requirements to full fill the scope and arrive at an estimation in terms of iterations. Now, allocate some budget for every iteration and track the costs. Within 3 to 4 iterations, project progress can be identified and if it is not as expected then trade off should be done after identifying root causes.
Every contract type has its own risks. I believe contract should be based on Value and acceptance criteria basis rather fixed time.
You could do a fixed price contract for a fixed duration, instead. Offer them a set number of iterations for a fixed price.
Please login or join to reply