Part 2: The Money - Put Your Money Where Your Mouth Is
You've heard it before:
- "We're going to be over budget"
- "We've used up our contingency"
- "We need more people"
- "X Department needs to charge our project code - we didn't plan for that"
How often has an original estimate been spot on? How much "wiggle room" was built into that plan already? What are you actually paying for anyway? Is it the "project" or the labor cost of the people developing and maintaining a product? If the majority of the cost of a software development effort is the labor, then why do we continue to treat it as an "unknown" that needs to be "estimated"?
Consider this - If a team of 10 people costs about $1.5M per year, then they cost $1.5M per year no matter WHAT they're working on. The power you have as the executive is to drive a change from project based costing to a capacity funding model.
When you move to capacity funding, you are investing in the teams, which allows you to focus on what output you're getting from each of your teams for the amount you've invested. If it's not meeting your expectations, then your conversations change from reacting to the "excuses" of not performing and delivering to:
- What's keeping this team from being better?
- Are they always working on the most valuable things?
- Do we need to adjust our investment levels across teams?
Capacity funding allows for adaptive planning. Doing an annual budget based on what projects you think you will work on 6-18 months in the future is wasteful. Things will, and always do, change. Course correcting every 3-6 months to stay aligned with strategic objectives, changing markets, and/or allowing for innovative game changers to ramp up and deliver quickly. That's Agile. By going beyond a directive that states "we are going to be Agile", changing a long-held belief around how software development should be budgeted shows you are willing to upend long-held beliefs in order to make the entire organization successful.
But pursuing a move to capacity funding in isolation only addresses the "money" part of the organization. What about the need to deliver faster regardless of budget? That's the topic for the next installment: