Atomic’s Custom Software Pricing and Payment Model

Atomic Object has been building custom software products for more than 20 years now. We have lots of experience building complex custom solutions for our clients. And we’ve seen lots of different ways of contracting for that work. There are two common models for pricing and payment on software development contracts. The first is the Fixed Fee or Fixed Price contract. And the second is the  Time and Materials contracts.

Each of those models has strengths and weaknesses. Atomic Object approaches contracting using a variation on these we call Fixed-Budget, Scope-Controlled. Here, we’ll explore the two common models and describe the power in Atomic’s Fixed-Budget, Scope-Controlled approach.

Fixed Fee Contracts

In a Fixed Fee (FF) contract, the client pays the software development contractor a fixed amount for performing a set amount of work. Here, the time and cost of the work are all fixed. And, for a FF contract to be successful, it must clearly define and fix the scope of the work.

Often in FF contracts, there is a pre-payment to start and then milestone-based payments along the way. And at the end of the work, there is a final milestone payment, typically after the team meets user acceptance criteria.

One example of where you might find FF contracts is in building a marketing website. Most follow common patterns that are familiar to users. Much of this work is done on popular content management systems. Furthermore, when all the content and branding are known ahead of time, an FF contract will help the client manage costs.

There are a couple of problems with an FF contract for custom software development projects.

First, this type of contract has little-to-no flexibility for the client. When faced with a lot of unknowns and a need to discover the product solution, the FF contract has no way to incorporate learning into the product. The only way to do this is by reestimating all the work and submitting a new contract or a variation called a Change Order.

Also, in an FF contract, the contractor takes on all the project risk in the work. Because of this and the time constraints, contractors will often make decisions that reduce the quality of the work (cutting corners). What’s more, software contractors will add buffer dollars in the FF contract to accommodate unknowns. That means the true cost of the work is often obscured.

Time and Materials Contracts

In a Time and Materials (T&M) contract, the client pays the software development contractor a fee based on how much time they spend and how much material they use. Often this is an hourly rate for each software maker on the project. In the T&M contract, the time and cost for the work are not fixed. Additionally, the scope can be very fluid. This is the exact opposite of the FF contract.

This type of contract is the most flexible in terms of adapting to change in the product work. As a result, it’s highly-desired by software consultancies that use an Agile software development model.

But it is also the most dangerous contract for clients. They own all the risk. And if no constraints exist, the project can quickly turn into a runaway spending of money with little to no value delivered.

Atomic’s Fixed Budget, Scope Controlled Contracts

Recognizing the weakness in both of these two common contract models, Atomic prefers a variation that offers both control and flexibility.

Our preferred approach is what we call the Fixed Budget, Scope Controlled contract model. Here, we discover a budget for the work through our pre-project consulting efforts, using various estimation techniques. We capture that budget in a spreadsheet and share it transparently with the client. This budget is fundamentally based on an hourly rate of work for each software maker on the project over a set period of time. As such, this is fundamentally a T&M contract with a Not To Exceed limit.

We’ve written extensively on this approach and use it successfully with all our projects.

The power in this contract model is that it allows the scope to change based on what developers learn as they build the product. And yet it sets a real constraint on the project across dimensions of time and cost. Risk in the project is mutually shared between the client and the contractor. As such, it gives the highest chance for success in the work that we do.

Approaches to Estimating

With our Fixed Budget, Scope Controlled project, we’ll use a couple of techniques to arrive at a recommended budget. We base the specific techniques we use on what we learn about the goals of the project, the problem that needs to be solved, and the project pattern needed for finding a solution.

One technique is to decompose each feature that will make up the final solution. We can apply this approach when we have a good sense of what the final product may look like.

On the other hand, if the project is a long-running effort and very complex, we may simply estimate a software development team over a block of time. This approach works well within large organizations and allows us to make plans to scale the team up and/or down as needed. We can do a series of smaller contracts and manage the overall program to communicate progress, learnings, and changes in scope or goals.

We may also look at past projects that are similar in technology and features. Based on the real data we have about the time to complete the work and adding in a factor to handle the difference in complexity, we can provide a comparison estimate.

Finally, we can apply the 20 years of experience we have in building custom software and come up with a “gut estimate.” With all these different estimation approaches, we can triangulate a reasonable budget that doesn’t undercapitalize the product development effort.

Finding Success in an Atomic Contract

As the project progresses, we track our hours worked and the features completed. We work closely with our clients, meeting with them weekly to discuss the status of the project. Part of that weekly discussion involves reviewing the financial health of the project. We are transparent about the budget we’ve consumed and the progress made on the project.

As the project proceeds, there will be opportunities to learn from what we’ve delivered and ensure we are moving in the right direction. The fact that we are not constrained by a contract with a fixed scope allows us to mold the project to take advantage of new information. The outcome is a better product that meets the needs of its users. And, because we are actively monitoring and managing the budget, the client feels in control of the direction of the project.

Further, changes in scope are reviewed to determine the impact they have on the project. If these changes mean a risk of exceeding the budget, we can make changes to the scope that offset the increase. We can either move less-important features to a later release, or we reduce the complexity of a specific feature.

While a budget is not a fixed price, it is a number we actively work toward meeting. Atomic has a history of meeting its budgets on time. Best of all, if the team crushes the work ahead of schedule, the client ends up saving money on the contract.

A Fixed-Mindset Trap

The biggest trap I’ve found in working with clients inside of flexible contracts is a fixed-feature mindset. This is the idea that the team must deliver certain features for a set budget in a given timeframe.

In custom software, when the problem is known but the solution is not, it is up to the project team to discover what features they can deliver for a set budget. The estimation techniques are an attempt to learn what budget is needed to deliver some success of the project. The more complex and undefined the solution is, the less accurate the estimation will be. And, at the end of the day, it is just an estimation.

If there are must-have features, then the project needs a Research, Design, and Planning engagement to reduce the risk and uncertainty in the recommended budget. Short technical software development work can also be performed to test possible solutions and further learn the effort involved in building out must-have features. And the team can conduct user research to learn if the must-have features will deliver on the goals of the project.

Despite all this, however, there is no feature certainty in custom software projects with fixed budgets. Risk can be managed. And scope will change. If the client is not willing to learn and adapt as the team builds the product, then it’s probably best not to do the project with a software consultancy that uses a flexible contract model.

The Right Software Development Contracts

What pricing and payment you use will depend on what your organization has done in the past and the relationship you have with your software consultant partner. Look closely at the work you are asking your software partner to perform. If the problem you are solving is well understood and the solution already exists, then you should take a FF contract approach.

However, if the solution is unknown and flexibility is needed, consider a contract like Atomic’s Fixed Budget Scope Controlled model. We believe it is the best way to find software success in a gray and uncertain world.

Want to learn more on how Atomic approaches custom software development contracts? Read Shawn Crowley’s excellent series starting with Writing a Great Software Dev. Contract, Part 1 – Overview & Principles.