14 SECURE FUNDING
Key Points in This Chapter
• We should gain agreement on the funding strategy for our initiative.
• Fixed-price funding is the riskiest option available to us, and luckily we have much better options available.
• Stable funding of value streams, rather than project-based funding of software teams, is an extremely effective approach.
The Secure Funding process goal, shown in Figure 14.1, provides options for how we can obtain funding for the team to continue on into Construction (and beyond). The Secure Funding process goal is important to most agile teams because, at least initially, they need the money to pay for development of the solution. In the case of dedicated product teams, discussed below, they may eventually become self-funding, where the revenue or cost savings from their solution is sufficient to pay for the ongoing cost of development. Until the team is self-funding, they need some “seed funding” to get started.
Figure 14.2 shows the high-level flow between the Finance process blade, the Portfolio Management process blade, and our team [AmblerLines2017]. The team will have received sufficient funding for Inception—this is typically provided by our organization's portfolio management activities—but additional funding will need to be justified based on the vision for the team (see Chapter 13). In fact, the portfolio management effort itself, as well as any efforts to explore potential product ideas, would also need to have been funded in some way in order to get us to this point. As you can see in Figure 14.2, this funding is typically provided by our organization's finance efforts. Note that in smaller organizations finance and portfolio management efforts are often addressed by a single team, whereas larger organizations are likely to spread these functions across multiple collaborating teams.
When securing initial funding for a team, we need to consider three important questions:
• How will we fund the team?
• What type of team are we funding?
• How will we access those funds?
Choose Funding Strategy
We need to select the strategy that will be used to fund our solution-delivery team. The strategy selected will have a significant impact on the behavior of the delivery team in terms of quality delivered and willingness to embrace changing requirements. The following table compares and contrasts several strategies for funding solution-delivery teams.
| Options (Ordered) | Trade-Offs |
| Charge by feature. Features, such as the addition of a new report or implementation of a new user story, are funded individually. | • Enables bidding on individual features, supporting a very flexible approach to evolving requirements.
• Suitable for outsourcing but generally not used for internal development.
• Requires significant involvement and sophistication of stakeholders.
• Funding to address technical issues, such as paying down technical debt, is likely to be starved out. |
| Cost plus. A variation on time and materials where a low rate is paid for a developer's time to cover their basic costs with delivery bonuses paid for the production of consumable solutions. This is also called “outcome based” or “cost reimbursement” [W]. | • Works very well for outsourced development, spreading the risk between the customer and the service provider because the service provider has their costs covered but won't make a profit unless they consistently deliver quality software.
• Low financial risk for both the team and for stakeholders.
• Requires active governance by stakeholders and a clear definition of how to determine whether the project team has met their service-level agreement (SLA) and therefore has earned their performance bonus. |
| Time and materials (T&M). With this approach, we pay as we go, paying an hourly or daily rate (“the time”) plus any expenses (“the materials”) incurred [W]. | • Low financial risk when teams are governed appropriately.
• Requires stakeholders to actively monitor and govern the team's finances.
• In the case of outsourcing, vendors should provide complete transparency such as task boards so that stakeholders are confident that they are getting value for their money. |
| Stage gate. With this strategy, we estimate and then fund the project for a given period of time before going back for more funding. This is effectively a series of small fixed-cost funding increments [W]. | • Medium-level financial risk as it provides stakeholders with financial leverage over a delivery team.
• Some organizations have an onerous funding process, so requiring teams to obtain funding in stages can increase their bureaucratic overhead and risk of delivering late.
• Except for the Inception phase, funding should be tied to delivery of increments of working solutions, not paper-based artifacts. The stage gates could coincide with DA's Stakeholder Vision, Proven Architecture, and/or Continued Viability milestones as a component of our agile governance. |
| Fixed price/cost (ranged). At the beginning of the project, we develop, and then commit to, an initial estimate that is based on our up-front requirements and architecture modeling efforts. The estimate should be presented as a fairly large range, often +/-25 % or even +/- 50 % to reflect the riskiness of “fixed price” estimates [W]. | • Ranges provide stakeholders with a more realistic assessment of the uncertainty faced by the team.
• High financial risk due to the initial estimate being based on initial requirements that are very likely to change and a potential for technical unknowns.
• To narrow the range, we will need to do significant up-front modeling and planning, thereby increasing our cost of delay and overall risk of incurring waste.
• Many stakeholders will focus on the lower end of the estimate range.
• Many stakeholders don't understand the need for ranged estimates, and we will likely need to educate them on the concept. |
| Fixed price/cost (exact). An initial estimate is created early in the life cycle and presented either as an exact figure or as a very small range (e.g., +/- 5 % or +/- 10 %) [W]. | • Very high financial risk due to likelihood of changing requirements and technical unknowns.
• Provides stakeholders with an exact, although almost always unrealistic, cost to hope for.
• Works well when we are allowed to drop scope to come in on budget, otherwise quality will suffer, which eventually drives up total cost of ownership (TCO) in the long run.
• Doesn't communicate the actual uncertainty faced by the project team and sets false expectations about accuracy. |
Choose Funding Scope
We need to select the type of team that we will be funding. As you can see in the table below, we have options.
| Options (Ordered) | Trade-Offs |
| Value stream. The funding is for the entire value stream, including solution development, IT operations of the solution, and the business operations of the solution [W]. | • Supports a more holistic view of value generation within our organization.
• Works very well with modern, rolling-wave budgeting processes.
• Value streams often cross organizational boundaries, yet funding mechanisms in many organizations do not, making it difficult to adopt this approach. |
| Line of business (LOB). Provides funding for a LOB or division and lets them fund teams accordingly [W]. | • Provides significant flexibility to the LOB.
• Still requires the LOB to fund teams in some manner. |
| Product (long-lived) team. The funding is for a team to develop multiple releases of the solution over time, potentially many years. | • Estimating costs for a dedicated product team is very easy (it's the number of people times our charge-out rate).
• Works very well with modern, rolling-wave budgeting processes.
• Out of sync with the annual budgeting process in most traditional organizations. |
| Project team. The funding is for a team to develop a single release of the solution. Project-based funding is often, but not always, limited to a single fiscal year at most [W]. | • Limits the scope and timeframe for funding.
• Fits in well with organizations still taking a project-based approach to solution delivery.
• Estimating costs for a project team can be quite complicated due to the variable staffing needs throughout a project and the difficulty involved with predicting the schedule of a project. |
Access Funds
There are various ways in which we can provide access to funds.
| Options (Ordered) | Trade-Offs |
| IT funding pool. Funds are drawn as needed from an organizational budget (such as the IT or LOB budget). This is basically a “take what we need” approach. | • Works well for high-competition situations where time to market is critical.
• Requires ongoing monitoring of how the funds are being invested.
• Requires a high-trust environment. |
| Informal request. A straightforward and simple request for funds is submitted by the team. This request is often made via a presentation to the finance team. | • Low overhead and potential to be fairly responsive; supports lean financial governance.
• Does not provide the documentation, and the false sense of predictability that accompanies it, that traditional governance people often expect. |
| Formal request. Comprehensive request for funds, often requiring documented value assessment or cost/benefit calculations and a presentation to the finance team. | • Fits with more formal or traditional approaches to financial governance.
• High overhead, particularly for smaller efforts.
• Provides a false sense of control or predictability. |
