Secure Funding

This Inception process goal describes how we obtain funds for the team. To be effective, we need to consider three important questions:

Secure Funding


Choose Funding Strategy

You need to select the strategy that will be used to fund your solution delivery team.

Options (Ordered) Trade-Offs
Charge by feature. Features, such as addition of a new report or implementation of a new user story, are funded individually.
  • Enables bidding on individual features; Suitable for outsourcing but generally not used for internal development; Requires significant involvement 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 developer’s time to cover their basic costs with delivery bonuses are paid for production of consumable solutions. This is also called “outcome based” or “cost reimbursement.”
  • This spreads the risk between the customer/stakeholder and the service provider; The service provider has their costs covered but won’t make a profit unless they consistently deliver quality software; Works very well for outsourced development; Low financial risk for both the team and for stakeholders
  • Requires active monitoring 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 you pay as you go, paying an hourly or daily rate (“the time”) plus any expenses (“the materials”) incurred.
  • Significantly lower financial risk when projects 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 you 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.
  • Lowers financial risk compared with fixed price; Provides stakeholders with financial leverage over a delivery team.
  • Some organizations have an onerous project funding process, so requiring teams to obtain funding in stages can increase their bureaucratic overhead and increase 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 Project Viability milestones as a component of your agile governance.
Fixed price/cost (ranged).  At the beginning of the project you should develop, and then commit to, an initial estimate that is based on your up-front requirements and architecture modeling efforts. The estimate is presented as a fairly large range, often +/- 25% or even +/- 50%.
  • Ranges provide stakeholders with a more realistic assessment of the uncertainty faced by the team.
  • To narrow the range you will need to do significant up front modeling and planning, thereby increasing your 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 You will likely need to educate some of your stakeholders regarding the desirability of a ranged estimate
Fixed price/cost (exact). An initial estimate is created early in the lifecycle and presented either as an exact figure or as a very small range (e.g. +/- 5% or +/- 10%).
  • Provides stakeholders with an exact cost to hope for; Works well when the scope of what you need to deliver is allowed to vary.
  • Doesn’t communicate the actual uncertainty faced by the project team; Sets false expectations about accuracy; When scope and schedule are also fixed it motivates questionable behavior on the part of IT professionals


Choose Funding Scope

You need to select the type of solution delivery team that you will be funding.

Options (Ordered) Trade-Offs
Value stream. The funding is for the entire value stream, include solution development, IT operations of the solution, and the business operations of the solution.
  • Takes the overall cost of, and value generated by, the entire endeavor; Supports a more holistic view of value generation within your 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
Product (long running) team.   The funding is for a team to develop multiple releases of the solution over time, potentially many years.
  • Estimating costs for a product team is very easy (it’s the number of people times your charge-out rate); Works very well with modern, rolling-wave budgeting processes
  • Out of sync with the annual budgeting process in most 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.
  • Limits the scope and time frame 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 difficult to predict schedule of a project


Access Funds

There are various ways in which you can provide access to funds for solution delivery teams.

Options (Ordered) Trade-Offs
IT funding pool. Funds are drawn as needed from the IT budget. This is basically a “take what you 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. Straightforward and lightweight request for funds is submitted by the team. This request is often made via a presentation to your IT governance body.
  • Low overhead and potential to be fairly responsive; Supports lightweight 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 your IT governance body.
  • Fits with more formal or traditional approaches to IT governance
  • High overhead, particularly for smaller efforts; Provides a false sense of control or predictability


Leave a Reply

Your email address will not be published. Required fields are marked *