Typically, when we buy something, we want to know what we’re getting for our money, right? It certainly makes sense. For instance, when I go to a burger joint and lay down a crisp $5 bill, I know I’m going to get a cheeseburger and can anticipate the quality, ingredients, and other aspects of that burger.

However, with Software development (among other things), pricing has traditionally been a challenge. The classic scenario has been along the lines of:

1. Client tells Software developers requirements X, Y, and Z at varying levels of details (ranging from ‘none’ to ‘some’, never ‘all’).
2. Client needs a price for the work to be delivered to be able to budget and assure their higher ups what the deliverable will be.
3. Due to the number of unknowns and assumptions needed to provide a price, Software developer cannot provide a price with confidence, so they add in a great deal of padding to the price to account for the risk of the unknowns.
4. Sometimes the client will accept this price, other times not (which isn’t good for the Software developer’s business)

Assuming the customer agrees to the price, the Software developer must now be hyper vigilant about calling out what is additional scope at every step along the way. This can lead to a tumultuous relationship of being at-odds instead of having a shared goal, and the client feeling nickel and dimed throughout; certainly not a smooth journey. In fact, 67% of consumers cite bad experiences as a reason for churn in what businesses they choose to work with.

What we all need to know, and collectively agree on, is that it doesn’t have to be this way!

Assuming you are up to speed on what “Scrum” or “Agile” means when it comes to Software development, it is understandable that this methodology can butt-heads with the classic “fixed price, fixed scope” pricing model typically seen in waterfall Projects. Here’s why:

• Customer’s Needs Change: Customer’s needs will continually evolve for a variety of reasons (competition, technology, etc.), therefore not collecting their feedback and turning it into new or adapted feature sets, is a mistake. It’s been measured that 70% of companies that deliver best in class customer experience use customer feedback. Organizations and Teams that can adapt the quickest will win in the 21st century.
• Business Environments Change: The needs of your business today will change from what they will be in a week, a month, a year, and so on. Why try to predict and box yourself and your Software development partner into a set of features/functionality that constrains you today against what you will need in the future? No one has a crystal ball. Release in small increments and collect feedback along the way from your customers. Use this to change your priorities and build the next iteration. To maximize success, have a contract in place that supports this way of working.

GE has realized this, and even though they are a gigantic organization, the company is putting the necessary changes in place to change how they work and build products to be more lean.

The future: projects priced according to Fixed Budget, Flexible Scope!

One concept that has proven its results in helping to price a Scrum project and show the value of said project, is called Continuous Innovation.

The idea behind Continuous Innovation helps clients with the following:

• Predictable Budget. So define a fixed budget up front, but, be able to flex scope, within that budget, as the needs of the business and your users are evolved throughout the project
• Receive something built and working at set, regular intervals of time, also known as a sprint
• Be able to change priorities as needed because it is decided what to work on for each sprint with the client/product owner

It is crucial to explain to a client, or prospective client, that value will be added at every single step of their project within the Continuous Innovation model. However, no one has a crystal ball to predict up front in a project what exactly that value will look like along the way. Having a Fixed Budget, Flexible Scope allows for a Software developer to say to a client, “you will get x sprints worth of value, in x amount of time.”

Having this type of agreement up front aligns both teams (Software developer and client), and helps nurture a collaborative environment where they can brainstorm freely together and adapt to changes along the way.

So if you’re still chasing “Fixed Budget, Fixed Scope”, hoping some day you’ll get exactly what you need for that original budget, without any surprises, you’ll probably be chasing for a long time. I want to let you know that it doesn’t have to be that way. Fixed Budget, Flexible Scope works, and I encourage you to embrace this modern concept so that you are setting yourself up to be able to deliver what your customers need, when they need it.