7 efficient ways of contracting dedicated software product development

There are a few quite good approaches to building dedicated software products other than fixed price and fixed scope approach. If you still think that you should even consider a “fixed price, fixed scope and doubtful quality” contract please read this article before you will move forward.

I have collected a few contract types (or actually a few variations of contract types) and built a list ordered from the approach I believe is the worst but still acceptable to the one I believe is the best.

Software product development

You need to notice that whenever I am writing or talking about software product development, I am never talking about project development but always about product development. There is no place for a classical “project” approach in the contemporary world when most of the products are online or at least connected to the internet. Working on “projects” makes sense years ago where you have been releasing the product to production and then never (or rarely) change it in the future. Nowadays modern products are updated even a couple of times per day and usually, with a scale, there is more than one version of the product that is currently on production.

Also, success in IT products is redefined as a state that the product could achieve but also could lose after time.

So since we know that we are talking about contracts for software product development, not projects here you can find a list of contract types I believe have the most sense. At the end of the list, you will find the most recommended one. At the beginning the least evil one – still OK for most of the cases.

1. Partially-flexible scope, fixed time (deadline), and fixed budget

Since we already know that the fixed price and fixed scope contract do not make any sense we can think about manipulating one of the dimensions. We also know that fixing the entire scope does not make sense from the business point of view. So when formulating the contract you can agree with a software supplier to split the scope that you are aiming for into two categories where the part of the scope is fixed – must-have features, and some part is flexible – nice to have. The budget is estimated for the entire scope but the flexibility of some of it generates a room for a supplier to address the risk of the unknown and the space for changing flexible parts of the scope by the buyer for free when more will be learned.
Many software vendors practice quite similar contract types and even allow to change the entire scope but they charge extra for every change request. I believe that this is a dishonest approach where the buyer is always a victim since the scope is always changing (if it is not, you are doing it wrong).
In terms of the deadline, often software needs to be delivered by a given date because of some outside world reasons. Scope flexibility gives us a margin for mistakes in estimation. Also, you can agree with the supplier that the deadline means only the first version, production release, and the development continues after that date until the entire budget is not exceeded.

2. Partially-flexible scope, flexible time, and fixed budget

In this type of contract, we also agree for the part of the scope that is must-have and the part that is nice to have and could be changed. We just remove the time boundaries. That leaves room for the vendor to manage the work in the best way for them to decrease the costs.
The work is done until there is a budget to perform it. The buyer could change the flexible part of the scope as he wishes. It is worth remembering that frequent scope changes decrease the team efficiency regardless of the development process they use. So it may occur that because of changing the scope many times at the end of the day the buyer will receive subjectively less functionality than if the scope would remain unchanged

3. Partially-flexible scope, fixed time (deadlines for milestones), and monitored hard-capped budget

As before, here we also split the scope into a fixed and flexible part. Changes in the flexible part could be of course made for free. We build the roadmap and set some milestones that include some features from a fixed part of the scope as well as some flexibility. Deadlines for milestones are fixed but with some room for a flexible part of the scope, it is not so difficult to manage it. Also, setting and reviewing milestones is a good way for the buyer to monitor the progress of work and see that it is going according to the plan. From the vendor perspective, this is a good way to build trust.
The budget is not fixed but hard-capped. That means the buyer will not pay more than the agreed price but could pay less if at some moment in time he will decide that what he already received is enough. Milestones are helpful here as well. Also, the budget is continuously monitored and the amount that is left is compared to the scope that needs to be done.
This is the contract type our clients often choose to start the cooperation with us. Usually, after learning of how many scope changes they needed on the go we smoothly move to the 4th contract type on our list. Then after achieving the goal usually our contract is altered to fit the 5th or 6th contract type from my list. There is nothing wrong to start at this stage. We understand that trust is something we have built with time, it is not something that we can always get for nothing.

4. Flexible scope, fixed time (deadlines for milestones), and monitored hard-capped budget

This contract type is similar to the previous one but the entire scope is flexible. That means that the buyer could dramatically change their mind and pivot the entire idea into another direction. Yes, we had a few cases like that in the past. In some products, even the technology stack changed totally, not just the scope. Without flexibility, the buyer would not be able to do that and will be tightened to the scope that has no sense or will have to negotiate a new contract.

5. Flexible scope defined by goals, monitored budget, deadlines are driven from IT

This is in my opinion, the best way to manage the cooperation between a software vendor and the buyer. This cooperation model requires a truly mature team and a good understanding of the software development process by the buyer.
Instead of focusing on the scope, you can focus on the goals you want to achieve and build some frames that these goals are built into. You can leave product management to the vendor and just monitor the progress towards goals as often as needed and provide the feedback. Moving the creative part of product management into the team that does the work you can benefit from their previous experience and knowledge. Software vendors built many products in the past, that experience is priceless. Unfortunately, any kind of fixed scope cooperation limits benefits from that experience. Also, people who do the work, when they have a chance to decide what to do to achieve the goals are able to find better/cheaper ways to achieve the goal.
Monitoring the budget is something that you should do regardless if it is limited or fully flexible. This is just good practice. If it is not provided by your vendor you should do this on your own.
Instead of setting deadlines for IT, you can turn your organization to be IT-driven. It is much easier to make some business decisions about dates when you have 100% true information from IT based on empiricism. Instead of fixing the date upfront, monitor progress and ask the team about the dates on the go.

6. Data/Feedback-driven dynamic scope, flexible budget (driven by current opportunities), experiments instead of deadlines

This model works best for more mature products that are already in production. Data-driven scope definition is something that you should do when you have data. Optimization based on data might lead to great profits.
Increasing your product profitability also opens new budget opportunities. The budget could and will change with time and that will have an impact on the pace at which the product is developed. A good software vendor will assure some flexibility here.
Instead of talking about deadlines, you can focus on running one experiment after another in short cycles. A/B testing with let say weekly experiments could provide a lot of data and let you optimize your product to the extreme as well as quickly react to the market changes.
Of course, you need to have proper analytics in place and work with a vendor that has a good understanding of data.

7. Empirical partnership

In empirical partnership, the deadline, budget, and scope are flexible and change with time. A “partnership” requires trust. Trust could be built on the empirical evidence that both sides are trustworthy. A good way to prove trustworthiness is building the product in an incremental and iterative way and adjusting both the product and process around it based on the feedback.

After or even during each iteration, buyers see the progress and monitor the cost. That way trust is built. With time, vendors have a chance to prove not just trustworthiness but also efficiency and expertise in product development. That way both parties benefit the most. The vendor could use their creativity and experience in a proper way and the buyer receives great quality work. This model is truly a win-win situation. If the product is successful its development is endless so the vendor benefits from a stable source of income and the buyer benefits from a stable, motivated team that drives product development.

Summary

It is not easy to build the product in a buyer-vendor setup, but it is possible. When choosing your software supplier, check if they have such capabilities and ask how they are going to build your trust.
Regardless of the models above. The “best practice” I recommend is to always deliver the product in an incremental way. Deliver it early, deliver it often, and adjust the scope based on the feedback and data.