Fixed Price Software Development vs T&M vs Scope-Controlled

Atomic Object has been building custom software products for more than 20 years. We have lots of experience building complex custom solutions for our clients. Because of the complexity involved in building a great software product, software development projects are always more difficult to price than a product. 

As a result two different strategies for pricing services, such as building software, have traditionally been used by most companies. These are called “Fixed Price” and “Time And Materials”.

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 Price (FP)

In a fixed price software development agreement, 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 an FP contract to be successful, it must clearly define and fix the scope of the work.

Often in FP 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.

• Static Variables: Scope, Cost
• Flexible Variable: Quality
• Assumption: The estimate and plan are correct and will not need to be changed.
• Risk: On Consultant (Responds by inflating cost; may compromise quality if estimates are inaccurate.)
• Effect of New Information: Causes conflict about what’s covered by the scope vs. what requires a change order. New ideas are rarely incorporated.

‍

There are a couple of challenges associated with a Fixed Price contract for custom software development projects.

1. 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 FP 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.
2. Also, in an FP 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 FP contract to accommodate unknowns. That means the true cost of the work is often obscured. Also, they will vigorously fight any variations to the scope of the project during the development of the software. When variations do occur, there will invariably be an argument as to whether this change is included in the fixed price that was agreed to or not. If not, then it’s time to generate the dreaded “change order,” determine the new pricing and get the new pricing approved by the customer.

What appears to be a strategy for eliminating the financial risk to the client actually ends up introducing a new risk. By fixing the price and thus the scope of the project, we risk building the wrong product, or a product that doesn’t meet the needs of its intended audience.

Time and Materials (T&M)

In a Time and Materials 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.

• Static Variables: Scope, Quality
• Flexible Variable: Cost (and Timeline)
• Assumption: The client can afford to do whatever it takes to accomplish the scope.
• Risk: On Client (Consultant has no incentive to be efficient or monitor budget.)
• Effect of New Information: Either more scope — and more cost — are added to project, or the information is ignored because there’s no more budget.

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. The client will most likely have an internal budget they are monitoring and thus are de facto responsible for ensuring the actual amount worked is tracking to the estimated amounts.

Also, the client may still be reluctant to make changes to the project scope in an attempt to not exceed the estimated amounts given by the vendor. But if they do make changes to the scope, the vendor will easily agree to these changes and complete them. Why not? They are being paid by the hour regardless of what gets delivered or if they exceed their estimates.

So while the vendor has mitigated their financial risk, the client now shoulders that risk.

Fixed-Budget, Scope-Controlled (FBCS)

 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.

• Static Variables: Budget, Quality
• Flexible Variable: Scope
• Assumption: There are more ideas than money, so we’ll focus on creating the best possible product for the budget. We’ll learn as we go and reassess our scope and plan regularly.
• Risk: Shared by Client & Consultant (and therefore reduced)
• Effect of New Information: Scope flexes as client and consultant re-prioritize features, possibly moving some to 2nd release. Price and schedule need not be affected.

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.

As the project progresses, we track our hours worked on the project and the features completed on the project. 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 upfront on the amount of budget that we have consumed and the progress we have made towards completion of the project. 

As the project proceeds, there are many opportunities to learn from what has been completed and ensure that we are moving in the right direction. In some cases, this information comes from additional user testing of the design, early iterations of the product, or discussions with the team.

The fact that we are not constrained by a contract with a fixed scope allows us to mold the project as we go along to take advantage of new information. The final outcome is a better product that better meets the needs of its users. Because we are actively monitoring and managing the budget, the client has the information necessary to feel comfortable with these scope changes, and we can determine the impact the changes will have on the budget.

Changes in scope will be reviewed to determine the impact they have on the project. If these changes increase the scope to the point where the budget may be exceeded, we are able to review the remainder of the project and make changes to the project scope that offset the increase. We can either move other less-important features to a later release, or we could reduce the complexity of a specific feature to help bring the project back in line with the budget.

Actively managing the budget on a weekly basis does not normally happen in either a Fixed Price or Time And Materials pricing strategy. In both cases, the tendency will be to discourage any changes to the scope to eliminate increases in the price of the software. This is unfortunate because we learn a lot as the project progresses that can have a positive impact on the final product.

While a budget is not a fixed price, it is a number we actively work towards meeting. Atomic has a great track record of meeting its budgets.

We feel this pricing strategy helps us to collaborate and cooperate better with our clients. The financial risk is now better managed and does not fall solely on a single entity. Working together, feeling free to make scope changes as we progress, and having the information necessary to manage the scope and budget makes for a much better working relationship and ultimately a better product. 

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.

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.

Choose What's Best for You

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 pricing and budgeting for custom software projects? Watch Atomic's Co-CEO, Mike Marsiglia, and Atomic Ann Arbor's Managing Partner, Jonah Bailey, discuss pricing strategies here.

‍

This post was co-written by Jeff Williams and Dan Santoscoy.