Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Cost Management, IT Project Management
AGILE : Cost Management
Network:26



I have 2 questions , I need clarification.

In Agile projects what is the best way to manage cost?

Which one is high risk fixed bid or T&M ?
Sort By:
Network:1821



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.
Network:96220



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.
Network:253



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.
Network:329



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.
Network:36



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.
Network:253



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.
Network:705



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.
...
1 reply by Stéphane Parent
Jun 12, 2019 1:18 PM
Stéphane Parent
...
You can't do a fixed price contract for a fixed scope project using agile. After the first iteration, you will have a list of new/missed/misunderstood features that will make it unprofitable for the provider.

You could do a fixed price contract for a fixed duration, instead. Offer them a set number of iterations for a fixed price.
Network:96220



Jun 12, 2019 8:54 AM
Replying to SASANKA PANCHAMUKHI
...
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 can't do a fixed price contract for a fixed scope project using agile. After the first iteration, you will have a list of new/missed/misunderstood features that will make it unprofitable for the provider.

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

Content ID:
ADVERTISEMENTS

"A good composer does not imitate; he steals."

- Igor Stravinsky

ADVERTISEMENT

Sponsors