A common concern I get from Agile newbies is “how do I calculate the cost of my Agile project, if I don’t do all up front planning?” Actually, it turns out that when I leverage agile00 methods to simplify my project accounting, budgeting becomes much easier. I’m going to show you two approaches that leverage two powerful attributes of Agile projects and help calculate budgets for Agile teams.
Powerful Attributes of Agile Projects
Stable Team Roster
Project managers across the world agree that a key risk for any project is getting your people yanked off the team, or having new people thrown onto a team only at the last minute. This is the evil version of “Resource Leveling”, and it prevents any reliable forecast of a project burn rate. So, let’s see what happens when we request, nay demand, a stable team roster.
Rather than try to calculate the budget for Agile teams across 12 months, I want to simplify my problem. If we work in 1-month time-boxed iterations, I only need to calculate the budget of a given iteration. Let’s see how that works below.
Approaches for Calculating Budgets for Agile Teams
Using a Blended Rate
When I worked at Marriott International HQ outside of Washington DC, project managers did not have visibility into the people’s compensation. Instead, we used a common “blended rate” of $125/hour. HR estimated the total loaded cost of the organization came down to that one number. Let’s assume I have a team roster of 12 people, but 4 of them are half-time, yielding a total of 10 Full-Time Equivalents (FTEs).
=> $125 X 8 chargeable hours per day = $1,000 fixed burn rate per person per day.
=> $1,000 X 10 FTEs on my team = $10,000 fixed burn rate per day.
=> $10,000 X 10 chargeable days in a 2-week iteration = $100,000 fixed iteration burn rate.
Using Specific Labor Categories
In other organizations, the Project Manager has to capitalize labor costs according to specific categories. For that we can’t over-simplify the problem with a blended rate.
=> Annual loaded cost of each team member / number of theoretical iterations in a year = fixed burn rate per iteration for that team member
=> Sum (every team member’s specific fixed burn rate per iteration) = fixed iteration burn rate
In the example below, I run these calculations to derive a $19,350 fixed burn rate per iteration.
Having a fixed, reliable iteration burn-rate is killer. Once I have that budgetary metric, I finally have some compelling talking points around common conversations:
- “Mr. Client, our agile release planning session says the ‘social media’ initiative will take 5 iterations, totaling $250K. Is the projected upside worth the cost?”
- “Yes, Ms. Vice President, we can add that emergency feature. However, the team says that will take another 2 iterations costing $100K. Can you authorize the additional budget?”
- “Team, we have to be ruthless about bugs. Any bug that prevents us from going live will cost us $50K in an extra iteration, and I don’t want that coming out of my annual bonus.”
…or use the metric to argue against common project mistakes:
- “Sure, you can take the senior tester off my project. But that will cause my current iteration to fail at a cost of $50K. Plus the team feels it will add another 30% risk of missing the deadline for the remaining $200K worth of work. That puts the total financial impact at $50K + (30% x $200K) = $110K. Are you prepared to eat those costs as well?
- “I know we are falling behind, but If we extend the iteration until we feel we are done, I have no way of forecasting the financial impact. However, if we simply extend the project by one extra iteration, I can tell you it will cost exactly $50K.”
What about you? Have you found Agile projects to be easier or harder to budget?