Fixed Budget, Variable Scope: A Modern Approach to Budgeting Custom Software

Fixed budget and variable scope is an agile approach to budgeting and building successful products.

At Kohactive, we develop custom software for our clients. Our work spans many industries and all types of products. In all of our engagements, we work with our client to learn as much as we can about the business challenge so we can figure out the best way to build the solution. While we don't focus on a particular industry, we've become experts in learning about industries and business challenges which translates into a tried and true process to get the most valuable product to market.

We’ve found that one of the more challenging areas when collaborating with clients is how we manage risk. Risks include:

  • Budget Risk: Will the budget available for a project be allocated correctly based on what will drive the greatest value?
  • Technology Risk: Does the technology exist to create the solution required?
  • Market Risk: Does the feature set align with the needs of the market it's trying to serve?
  • Management Risk: Will the resources be managed appropriately?

Organizations partner with Kohactive to reduce technology risk. Often, they will need more guidance on identifying the ideal way to build the solution to their problem, and we work with clients to determine what is ideal for their customers.

Setting a budget for a custom software project is challenging, especially with so many unknowns. Project budgets help reduce risk and control the project. But how do you manage a project when there are so many ideas and not enough money?

Let's look at the two most common pricing strategies that organizations use for building custom software: "Fixed Bid" projects and "Time and Material".

Fixed Bid Projects

Clients look for ways to mitigate budget risks too. They will often ask for "fixed bid" or fixed price projects. A fixed bid project is a type of project where the payment amount does not depend on resources used or time expended. Clients allow different vendors to bid based on the project with the hop a vendor will get close to their estimated budget.

  • Static Variables: Scope, Cost
  • Flexible Variable: Quality
  • Assumption: The project requirements are correct and will not change
  • Risk: On Agency

For the client, there are many upsides to a fixed bid project. For example, it's predictable, and they know exactly what they are getting and how much they are paying. However, a fixed bid project requires very detailed requirements and provide little to no room for deviation from the requirements. Fixed bid projects typically set the stage for scope creep because a fixed budget and milestones usually don't account for new learnings. Scope creep can also cause tension on the project as we usually tend to push back on any additions due to the extra risk it can bring to the project on Kohactive's end.

In regards to budget and management, it is very challenging — if not impossible — to estimate the cost (time and budget) of unbuilt features. To commit to a budget or schedule based on so many unknowns can exponentially increase the management and budget risks for Kohactive and the client.

Time and Material

Another budgeting option clients like to use is time and material where clients will pay for the time and the materials used to fulfill the project requirements. Time and material budgeting provides the flexibility needed for projects that will have a dynamic scope and gives the opportunity for clients and the Kohactive team to evolve and redefine the project scope over time.

  • Static Variables: Scope, Quality
  • Flexible Variable: Cost (and Timeline)
  • Assumption: The client has a large budget and good timeframe to complete the project in totality
  • Risk: On Client

Another benefit is we get an accurate cost breakdown of features and tasks and can make better decisions going forward on how resources should be allocated. Time and material, like any other strategy, has its drawbacks. Time and material projects have low budgeting controls in place which can lead to features and/or the project going longer and costing more than the estimated budget. Time and material also require deep team involvement to ensure all time allocated is contributing to advancing the project.

While we don't take full responsibility for managing all the risks involved in a project, we work with our clients to mitigate as much risk as we can to ensure the successful development of their project. This is why we like to stay away from fixed bid and time and material project and work on projects that are fixed-budget and variable scope.

New Way: Fixed Budget, Variable Scope

A more user-centric - agile approach, you’d tell us a budget, and we’d work to deliver a product to you in your budget. In practice, this means a lot of user-driven decision making, prioritization, and elimination of waste. We’d solely focus on identifying the minimum lovable product that you need to accomplish your goals. If you had other features you’d want to add, we’d have to prioritize based on what already exists in the backlog. In this case, we fix the budget and are more flexible in scope without sacrificing quality.

  • Static Variables: Budget, Quality
  • Flexible Variable: Scope
  • Assumption: We don't fully understand the scope and solutions yet but will use prioritization and communication to reassess the scope constantly.
  • Risk: Shared by Client & Agency

Here’s a step by step example of how it would work:

Plan

In the planning phase, we come up with a list of potential features based on importance and priority. We talk to clients, their end users and we use this information to re-align priority. While priority can change, having a master list of potential features allows the development team to plan out the development process. During our planning, instead of assigning hours, we assign “points” to each feature. These points are supposed to express the complexity/ estimate how difficult a feature will be.

Track and Build

Once we’ve identified the difficulty of each feature, we determine how many points we can do in one or two-week iterations, and we keep that as our velocity. For example, if the list of features prioritized for the week is a total of 20 points and we get 15 points worth of features done, we assume 15 points is our velocity, and it helps everyone forecast the number of features that can get done in the budget. Again, this is most likely changing based on feature priorities.

Show and prioritize

Depending on the client, we demo functionality on a weekly or bi-weekly week basis. The goal is to deliver functional demos that clients can touch and use. After showing the progress, we prioritize what gets done for the next iteration. This allows an opportunity to continuously learn and ensure we're delivering the most valuable product for your budget.

To us, this approach provides a more collaborative and accountable process. Both Kohactive and the client truly enter a partnership where we mitigate project risk instead of shifting to different stakeholders. We can bank on our capabilities to deliver. We have strategies and processes in place that have delivered within budget and fixed timeline. Our discovery process along with our project management methodology helps us to deliver consistently while prioritizing what drives the most value for the customer.