Please login or join to subscribe to this thread
There is no difference between projects running with Agile approach or not. First question: when somebody provide you an estimation, do give you a number or a range? if it is not giving you a range then you are lost. Why? Because is not considering that estimation depends on information you have then depending on the moment of the estimation the risk of do not have enough information will impact the estimation. This is not new. This was well documented from long time ago for people like Barry Boehm (Cone of Uncertainty) or Steve McConell to name just two. So, my recomendation, is review all the estimation process and mainly the method: if you are using story points then transform it into hours is the worst mistake you can do.
It sounds like either the work statement has grown to include unforeseen work along with the planned work, or people are overestimating how much work they can do in a given time period (velocity). If you want to find the root cause, go back and compare estimates to actuals, and ask why the delta.
Agile is best suited where both complexity and uncertainty are high. There will be unexpected work. You need contingency reserves to cover the unplanned work. I've had very new and unique projects where we added on 40% to the bottoms-up estimate. We didn't know what we would need it for, but we knew there would be big issues and we would need those reserves, just not for what.
If you look at your past projects and find they're about 20% over budget on average, I'd recommend padding the budget by at least that until you get a good grasp of either the true velocity achievable by the teams, or the typical amount of unplanned work.
That reserve is held at the project level. If each contributor adds reserve and you pad it more, you are overly cautious and can price yourself out of winning contracts. Also don't advertise the reserve. If people know there is a big slush fund for teams that go over budget, everyone will plan on spending all the reserve and then some.
There could be many reasons for this so it would help to do some analysis to understand what the vital few causes are.
It could be a case of initial estimates being too optimistic but it could also be caused by:
1. Lack of discipline on working towards a defined vision. Agile does not mean a random walk to nowhere.
2. Lack of reliable allocation of staff to teams. If team composition varies over time and if there is a fixed cost per unit of elapsed time, projects will end up costing more
3. Cost of poor quality. If agile is perceived as meaning "deliver quick" then corners might be cut and more effort spent in rework and repair
These are just a few possible causes, so root cause analysis is needed...
I agree with Sergio.
I would start by examining your team's flow, paying extra attention to when the work is estimated and when estimates are refined. Here are some starter questions:
* Are the app owners also the developers?
* Are developers sizing the work before development begins?
* Do you refine the project cost estimate/budget as you learn more?
I think Sergio was right to bring up the cone of uncertainty. If your app owners aren't developers, and your developers aren't able to ask questions about the work as part of the estimating process, to build out the story, test cases, acceptance criteria, etc..., you're starting with a ROM estimate, which can have a variance of at least -25% to +75%.
Look at the process from identifying the work to be done to selecting the work to do and then performing the work. At each point, you are able to refine what you know about the work and how long it will take. If you're not already, involve the developers in the initial estimates.
These are just some initial thoughts. I'd want to understand more about your team's flow to be more specific about where to start.
One of the issues we have in project delivery when it comes to budget and costing is assuming the initial estimate or budget is right and that the problem is inefficient use of resources or costs during implementation. When faced with this problem I typically start by assuming the budget was wrong. There are a number of reasons why this may be the case:
1) adjustments to budgets to get approvals
2) estimators are too far from the front line
3) scope is nebulous
4) optimism is always higher in the beginning
5) failure to recognize project risks
There may also be a number of reasons that costs are escalating:
1) poor scope management
2) ineffective resource assignment
3) lack of effort monitoring and reporting
I would suggest a comprehensive post mortem on one (or two) failed project to try and narrow down the main factors. Don't limit the post mortem to implementation - start at the beginning. Use the results as lessons learned.
In an Agile framework, your cost per iteration should be based almost solely on the team. If you keep your team members constant, then your iteration cost will also be constant.
Each iteration will consist of all the backlog items the team can fit. Since the team is prioritizing the work and delivering the most valuable items, the next question becomes how many iterations are you--or your customer--willing to pay for?
The problem is usually twofold: using an absolute measure for your estimates, such as hours or day, and committing to completing all of the work items in the backlog.
There's a reason why we shy away from estimating too early and using monetizable values. As soon as you do either of those things, you are trying to fix the scope of the project. Agile approaches are deliberately used to avoid fixing the scope.
Please login or join to reply