Castellan Systems

A critical success factor for a software development project is how it is funded. This will drive many aspects of the team’s behaviour throughout the project.

The greater the flexibility of the funding strategy, the greater the chance the team will produce a quality product and the greater the chance that they will delight their stakeholders. But greater flexibility generally requires a more skilful approach to governance and project management.

These are very interesting trade-offs that can have a huge impact on the level of success for your IT efforts. In this blog I’ll explore several common options for funding software development projects.

Context Counts When Choosing a Funding Option

An important business agility principle is that context counts. This principle recognizes that different teams are in different situations, that there are no “best practices,” but instead all practices/techniques are contextual in nature.

Any given practice has trade-offs that work well in some situations but are unsuitable in others. To choose an effective way of working (WoW), you need to understand the trade-offs of the various techniques available to you, and then select the combination that works best for you given the situation that you face and the skills and culture of the people involved.

Recognizing this provides people with choices rather than prescriptions. Many methods or frameworks will promote a single way of doing things; in effect they have pre-selected the combination of practices they want you to follow. What you need instead is advice on what process decisions you should consider, what your options are, and what the associated trade-offs are. This will enable you to make better decisions regarding what will work best for you, rather than following a prescription of what it believes to be best.

For example, in Figure 1 you see the process goal diagram for how a team may secure funding. When doing so you need to identify a funding strategy (shown by the red rectangle), and identify the scope of what you’re funding (let’s assume a project team). Next, decide how the team will go about accessing the funds being provided to them (this is usually chosen by your organization’s finance group).

For each of these three decision points you see that you have options. This goal diagram is a bit unusual because all three decision points have ordered options, which is something that’s indicated by the arrows beside each list. In the case of ordered options, we’ve been able to rank the relative effectiveness of the options, with the most effective options towards the top of the list and the least effective options towards the bottom.

Other goal diagrams, not shown here, have unordered option lists sometimes. In these cases, every option has trade-offs, but we cannot honestly say one option is more effective than the others.

It is important to note that the rankings shown in Figure 1 are for software teams, although we suspect the rankings are likely to hold true for non-software teams too.

Let’s explore how the funding strategies depicted in Figure 1 compare.

Options for Funding a Team

As you see in Figure 1, there are six options for funding a team. Yes, there may be more strategies than this, and you can certainly combine strategies. However, the aim is to cover a representative range of options so that you know you have choices. From most effective to least effective, these funding strategies are laid out below:

1. Charge by feature: Features, such as the addition of a new report or the implementation of a new requirement, are funded individually.
2. Cost plus: This is a variation on time and materials where a low rate is paid for the team’s time to cover their basic costs with delivery bonuses paid for production of consumable solutions. This is also called “outcome based” or “cost reimbursement.”
3. 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.
4. 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.
5. 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 modelling efforts. The estimate should be presented as a fairly large range, often +/- 25% or even +/- 50% to reflect the riskiness of “fixed price” estimates.
6. 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%).

Table 1 overviews the trade-offs associated with the funding strategies described above. An interesting thing to observe is that the least risky, more effective funding strategies require more sophisticated approaches to financial governance than the less effective funding strategies.

“All teams and all projects can use Kanban,” said Grady Brumbaugh, a Kanban trainer at The Digital Innovation Group. “The work environment where Kanban thrives is one where delivery timelines are tight and those prioritizing the work can make a stack-ranked based decision.”

Funding Option	Advantages	Disadvantages
Charge by feature	Enables bidding on individual features, supporting a very flexible approach to evolving requirements. Suitable for outsourcing feature-based work but generally not used for internal development. Enables stakeholders to spend their IT investment wisely.	Requires significant involvement and sophistication of stakeholders. Funding to address technical issues, such as paying down technical debt, is likely to be starved out in favour of new functionality. Does not easily provide the false predictability required of traditional, and often annual, budgeting strategies.
Cost plus	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 business stakeholders. Enables stakeholders to spend their IT investment wisely.	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. Does not easily provide the false predictability required of traditional, and often annual, budgeting strategies.
Time and materials	Low financial risk when there is effective governance in place. Provides the flexibility to evolve the team as appropriate, matching team capacity to need. Enables stakeholders to spend their IT investment wisely.	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. Does not easily provide the false predictability required of traditional, and often annual, budgeting strategies.
Stage gate	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. Can be difficult to govern how the money is being spent when the stage gates are several months (usually quarterly) apart. Except for the Inception phase, funding should be tied to delivery of increments of working solutions, not paper based artefacts—the stage gates could coincide with DA’s Stakeholder Vision, Proven Architecture and/or Continued Viability milestones as a component of agile governance.
Fixed price/cost (ranged)	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. Also, fragile when significant technical unknowns exist. To narrow the range of the estimate we will need to do significant up-front modelling 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 and thereby have unrealistic expectations. Many stakeholders don’t understand the need for ranged estimates, and will likely need to be educated on the concept.
Fixed price/cost (exact)	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.	Very high financial risk due to likelihood of changing requirements and technical unknowns. Doesn’t communicate the actual uncertainty faced by the project team and sets false expectations about accuracy. When the team isn’t allowed to drop scope, they short-change quality, which eventually drives up total cost of ownership (TCO).

Choice is Good When Funding a Project

If you want to be effective then you must match your approach to the situation that you face. Because different teams face different situations, one single approach will not fit all, and instead you need to have choices which you understand and can apply appropriately.

More importantly, you need to be prepared to evolve your approach as your situation changes. As we’ve shown in this blog, you have a range of choices for how you can fund software development projects. Our recommendation is to do the best that you can in the situation that you face, and to always try to learn and to improve.

In Conclusion

Once you have your funding secure, then you’ll need to track expenditures. Castellan Systems’ Condotiero and Almogavar are project management applications that have the features you need to develop and monitor you budget. But it also helps you plan, schedule and report on your progress, while giving you real-time data so you’re always up-to-date.

Download this Guide