Traditional project funding works well when you’re on annual fiscal cycles or working on long-term capital projects. Data and experience show that funding IT projects like this provides the illusion of control, but inhibits delivering quantifiable value. Ultimately this is the antithesis of working in a manner consistent with Agile principles and will limit your success.

Using a low-code platform to speed up application development and business value delivery helps solve the technology and collaboration sides of the problem; however, slow-moving funding and a lack of clarity around who is footing the bill gets in the way of you delivering value as quickly as you could. The way we work is changing, but funding has not. So we need to make funding as flexible as possible.

Here are some new ways to ensure your IT project funding enables, not hinders, your low-code development processes and supports your digitization journey.

Why Traditional Funding Is Broken

The breakdown of traditional funding starts with a lack of focus on value or outcomes. In “An Introduction to Evidence-Based Portfolio Management”, by Scrum.org, the authors state, “Traditional portfolio management is principally concerned with three variables: cost, schedule, and output. These three variables, unfortunately, have little connection to value: Cost has a loose connection to value in that it might cost too much to deliver the value that customers desire, so high cost may make certain solutions undesirable; a schedule’s connection to value is also tenuous, as when an opportunity must be seized within a certain window of time or it becomes irrelevant. Output, or productivity, is only relevant when the right solution is being delivered.”

When your funding isn’t on the same wavelength as your value delivery system, the latter tends to break down. Users and customers’ needs change. Teams alter requirements. Change is inevitable and funding isn’t reflecting that.

Typically, project funding for IT organizations is performed annually. Those in charge of funding often anticipate projects and initiatives way off in the distance.

Traditional project management bases timelines and scope of work off of assumptions. Agile development mitigates that. The traditional funding process works the same way. It, too, tries to make assumptions about the timeline of each project and its costs. And when there’s traditional funding on top of Agile project management, the result is, as Delivery Manager David Thomas states in a blog post, “friction between the teams doing the work and the people agreeing the budgets.”

But things change. Always. And outcomes need to be delivered. Always.

With low code, addressing those needs and creating outcomes is easier to do than with traditional development. Using Mendix and an Agile way of working, you can quickly change the direction that a project needs to go in.

So how do you ensure you’re investing the right money into programs and projects that will ensure outcomes when needs change constantly?

New methods for funding

We are not suggesting that you replace traditional budgeting completely. You still need to have long-term vision and strategies. Getting the most value and ROI out of your low-code platform means applying funding methods that support shorter, strategic initiatives and standing those up next to the long-term plans.

To successfully stand up a low-code capability, try one of these more outcomes-focused funding methods.

Evidenced-based

With traditional funding all projects get funded 12 months ahead (whether they are successful or not). What you often see with this method of funding is that when budgets get under pressure at the end of the fiscal year, all projects’ budgets are cut down or cut out completely. With evidence-based you have full budget control and you develop based on value.

This method sets predetermined events that the team must meet before more funds are allocated to the project. Such milestones may include creating and going live with an MVP. Other milestones may be more outcome-based like achieving a KPI determined at the start of a project or realizing a pre-defined business value goal.

Team-based

Through a team-based method, rather than funding a project, the organization agrees to fund a group of resources that have a clear vision on how to execute a program using Mendix. While the outcomes for the project aren’t immediately clear, the funded team has goals they’re trying to achieve. This team determines and prioritizes the projects they’ll be able to execute based on the funding they receive.

A Mendix customer in the insurance industry began funding for the number of people that are on the low-code development team and allow a small budget for other data services or components they might need to buy. They build priorities with the business and then start delivering. No budgetary roadblocks.

Licensing

An issue we see a lot in terms of funding is the question of who is left holding the bag, so to speak, when it comes to platform license fees.

In our experience, we see central IT carrying the costs. It makes sense because they are the ones building the first applications. After delivery, demand from the business starts to grow, and requests for applications start to pour in. So now who pays for the platform costs and the costs of actually building the application?

The problem is that an unclear view of cost ownership prevents organizations from accelerating application development and value delivery. Central IT begins to cross-charge application license fees to the business; costs then run up even before building begins on the application. High costs can prevent an app from ever launching, which means value isn’t realized.

Our recommendation:

Whether you are starting with your first application or you are building over 100 applications: central IT carries the platform fees. There is no cross-charge on the application level for use of the platform. This results in a lower threshold for evidence-based funding, which supports Agile application creation and higher organizational agility.

At Mendix, we talk a lot about Start, Structure, and Scale when it comes to low-code success. This applies to funding as well. Here’s what it could look like across each stage.

  • Start – Central IT also funds all the roles needed to create a foundational low code capability (architect, cloud, security, etc.) as well as funding the development team itself. The team needs the room to learn, make mistakes, prove productivity, and increase it.
  • Structure –  At this stage, application development starts to move faster. Central IT continues to fund the platform license fees as well as the low-code center of excellence, but now the business starts to fund the development teams themselves, too.
  • Scale – At Scale, there are many different ways you can fund a project and keep licensing in Central IT.  A popular one is to embed low-code development teams directly into the business organization so that they can take full control over funding.

traditional project funding versus low-code project funding

It’s always about outcomes

Ultimately, you invest in a low-code platform to deliver more outcomes and value faster. Your budget should represent this, too. See how you can deliver more value with low code and click the banner below.