Fixed Budget Scope Controlled

Fixed-Budget, Scope-Controlled (FBSC) is applied at Atomic Object. They build custom software for our customers. 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”.

Fixed Price

• A Fixed Price strategy locks in the total price of the project upfront.
• 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.

In this strategy, the vendor is taking on all the financial risk of a project. They have committed to completing the project for a specific price. If they complete the job early, it’s a bonus for the vendor (and you the client has overpaid), if they don’t then the vendor loses. In order to mitigate this risk, they will want to know all that can be known about this project and the risks before it will commit to a fixed price.

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.

This is unrealistic, as it very difficult — almost impossible — to know everything that will affect the project at the very beginning of a project. Also, it makes it difficult for the scope to change over the course of the project as new information becomes known that helps us to create a better software product.

Thus 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

In a Time And Materials pricing strategy, the vendor will work on a project and bill for every hour worked without regard to any financial constraints. An estimate may have been created, but since they are paid regardless of whether they exceed the estimated amount, they don’t do more than just track their time.

• 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.

In this scenario, the client is taking on all of the financial 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. Unfortunately, what is missing here is what scope has actually been completed. Without this information, the client cannot accurately gauge the progress of the project and thus does not know if the estimate is going to exceed the estimate until it actually does.

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

We don’t feel either of these pricing strategies helps us to build better software within a responsible budget. So Atomic prices the services using a Fixed-Budget, Scope-Controlled (FBSC) strategy. In this strategy we work with our client at the beginning of the project to get a good understanding of the project. Using this information and our knowledge about building software, we then create a responsible budget. We do not fix the scope of the entire project upfront, we only fix the budget and time.

• 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.

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 customer. 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.

Source: https://spin.atomicobject.com/2014/08/25/fixed-price-vs-time-and-materials/