How we manage changing scope in a fixed price project

Most of the time, a client has a broad idea of what he or she actually wants. In order to transform that idea into a concrete digitised solution, we need to iterate through all aspects of the project. This is a hard task since many use cases may only become clear when the solution takes shape. And obviously, new use cases bring new insights and therefore necessary changes to the solution. But, if a scope and budget is locked-in at the start of a project, how do we adapt the solution to these changes without influencing the price? This is where “fixed price, flexible scope” comes in.

What is “fixed price, flexible scope”?

If a project has a ‘fixed price, flexible scope’ model, we start from a reference scope and according budget. A clear and thorough overview of the product requirements is written down before the start of the project. Next to this, the estimations of the needed work hours will be calculated precisely. Scope changes are possible because any additional cost is covered by excluding other functionalities of the reference scope in order to stay within the foreseen budget. As a result, the project will be balanced in a way that allows us to develop the exact solution the client wished for and allows the client to benefit from a fixed price.

To give you a more clear image of how this model actually works, we’ll further explain by using an example.

The photo gallery

A client named George wants an application to manage photos and it needs the following features:

• Photo gallery
• Grouping photos in albums

Later on, George learned about the wonderful world of machine learning and would love to have a feature in the app which can detect the contents of the photos and add tags accordingly. For example, a picture of a cat will be tagged as “cat”. This means we now have a new feature in scope:

• Photo gallery
• Grouping photos in albums
• AI to tag photos

Of course, at this point, the cost could only increase. Surely a new feature means the scope has grown and so the cost will increase as well? But that’s not necessarily the case, let’s revise the features... If AI can take care of tagging photos, then why not scratch the feature to group photos in albums? We simply group photos in albums based upon the tags the AI creates. As a result, we now again only have two features:

• Photo gallery
• AI to tag photos

Assuming that both features require the same effort and cost to implement, the budget is still in balance.

"Fixed price, flexible scope" in practice

"Fixed price, flexible scope" seems like a great selling point but isn’t this a horror story for developers? After all, the team has to develop an application that might change during the development cycle. Does this mean we have to throw some, if not all, of our precious code into the bin? Not at all!

Let’s take a look at how we tackle this challenge using the photo gallery example again. We’ll make the assumption that we’re storing the photos on a local disk where the server is hosted. Typically, a developer would write up some code to store, fetch, update, and delete a photo. All the functionality to store photos is coded into a DiskStorageService. But, after two months of development, George wants his photos stored in the cloud.

Welp! Now the developer has to rewrite the DiskStorageService to a CloudStorageService. This means double work and it requires refactoring the code quite a bit since the DiskStorageService is referenced throughout the whole codebase.

The above is a simplified, but typical example of a scope change. But, if we never coded the DiskStorageService in the first place and created a generic StorageService instead we wouldn’t encounter this issue. This is because StorageService means you can store photos in the cloud, on disk, or anywhere else. The key features are still store, fetch, update, and delete. In this scenario, the only code in need of updating are the aforementioned functions.

This can go even further. Imagine a search functionality for the photos. In order for George’s customers to be able to search for photos in his application, we’ll write up some code to search photos based upon their tags. But later in the development cycle, George also wants to search through his users. This scope change can be tackled easily if we wrote the search functionality in a way in which we only need to define the database table and columns which need to be searched instead of writing specific code for the photos only.

Anticipation is the key-word here. It’s not only a good coding practice to make the code abstract so it can easily adapt to new use cases but it is also very cost-effective and ideal for the "fixed price, flexible scope” approach.

If your project requires absolute flexibility, you can still choose the time-and-material model. The scope of the project can change easily, without the necessity of excluding other functionalities. Of course, the price will be influenced by the needed time, effort, and material. But, do you want a predictable cost? Then 'fixed-price, flexible-scope' is the ideal way to still maintain a certain degree of flexibility in scope.

If you are looking for more information tailored to your business needs, don't hesitate to contact us!