When we move to Agile we typically form our teams and then happily keep our waterfall project based funding structure in place.
We do this for a few reasons:
- We think it’s the only way to show the cost of the work that we are asking to be delivered.
- Projects are easily understood from an operational standpoint as they have a defined start and end date which is tightly aligned with the cost of the project.
- It’s the way we’ve always done it.
As part of our project based funding model we have an annual project funding request process, where we spend weeks/months identifying the things that we think are important (note I’m not using the word valuable here) so that we can obtain funding. Things move above or below the approval line and when the dust settles we have a book of work that is committed to, with freshly minted project plans and a cadre of project managers to manage the money we just gave to these projects.
An annual project funding request process also means that we ask for what we need and then everything else we may or may not need. We ask for a Ferrari when perhaps all we need is a good dependable family sedan.
There is power in money, who has it and who controls it typically drives what gets funded and what doesn’t. It’s not uncommon for Sr. Leadership to commit to work even though their team doesn’t have any experience in the product solely to get the money to keep their teams funded and employed.
If you see a lot of potential waste here then you are correct. We see waste just in the amount of people and money needed to manage our project money. If a money market fund had as much overhead associated with it, I and everyone else would leave because that overhead just cuts into profitability.
Next let’s more waste related to developing the stuff we didn’t need and may not actually use. All of this extra stuff we develop has an expense associated with it and this is a long term expense. We have it built into our architecture negatively impacting our systems scalability, performance and security. We have to test it every time we build new stuff. Bet you didn’t take that into account when you did your Cost/Benefit analysis for the project.
When we move to Agile we have an ability to really simplify our IT funding function. It’s really quite simple – it’s the cost of your team.
In most organizations this cost typically hovers around ~$40k per sprint or over ~2 million annually. So as a financial manager trying to manage things like cash flow, depreciation and the like, this makes financial reporting much simpler. Each team becomes a fixed line item cost on my balance sheet and operating statements. I don’t have to worry about cost overruns from project funding since the team is a fixed cost. Product Owners ensure our teams work on the most valuable things in a consistent manner and at the end of the year we should/can be able to gauge the value of that work to some accuracy.
So here’s a challenge that we face, how do we actually assess value? How do we value things like reducing technical debt to make applications technically better? How do we value writing an input validation security framework that makes our application safer for the user and ourselves? How do we value things that our customers aren’t asking for, but in the end benefit from? That is the core element of software development, there is significant value in the things that the customer never sees yet we place little effort or priority in delivering these elements. Instead we focus on the visual functionality and throw quality and architecture down the drain in favor of meeting project timelines.
If you get the fact that you have a fixed development cost it actually should foster better conversations regarding what is really valuable for the entire organization to be working on. Not your pet projects, not the projects you agree to only to get funding to keep your people employed, that’s not how real value and efficiency happens and it’s time we stop thinking that it does.
Agile highlights very quickly that an organizations planning and funding functions are broken. It also typically becomes clear that we don’t have a real grasp on what our real value streams are and finding them often means removing political barriers that have built up over years. Agile requires that we redefine what value is and organize our delivery across these streams over organizational silos.
The traditional PMO also goes under a dramatic shift, moving from managing projects and funding to ensuring that programs align to the organizations value streams, are well understood and organizational impediments are removed for the teams.
So if you are looking to move your organization to Agile you must understand that your funding and planning functions must change to align to a new mindset and paradigm. Funding is easy in Agile, really it is (remember it’s the cost of your team), uncovering your value streams and maximizing the work that flows to your teams that delivers that value, now that’s harder (but not impossible).