It’s very common to hear in this business that there are three aspects to a project that can be controlled, and only two can be controlled at a time: duration, cost, and quality. This isn’t one of those explainers.

I propose a different way of looking at this triangle. It’s not that you can’t deliver a quick, affordable, high-quality product. It’s that you can’t guarantee one. You can only make two guarantees at a time: duration and cost, duration and feature set, or cost and feature set.

I believe that most people understand this implicitly. If you tell me you need a coffee table tomorrow no matter what, I’m not going to tell you I’ll craft you the most beautiful table by hand or that I’ll deliver it for under $25. I’ll go to the Target near my house and get you an $80 coffee table in an hour. If you tell me you need it tomorrow and it needs to be under $25, I’ll go to Marshall’s later today. But if you tell me you need it by tomorrow, for under $25, and it needs to be handmade, I’ll tell you to make your own table.

Software clients are often put in the bad position of having to choose between quick, fast, and good, and then getting something they didn’t want, for more than they wanted to pay, later than when they need it. And behind the scenes, there are developers who worked weekends and holidays and missed their kid’s baseball games to deliver this product that doesn’t even meet the developer’s own personal quality standards. Although the client’s bill is higher than they expected, the development organization isn’t even billing for all of the time that was spent in development. If there’s a winner here, I can’t find one.

As a Solutions Architect, I can’t look away from a problem like this. As someone in a Product Owner role, I can’t tolerate an expensive, rigid process that delivers a low-quality product.

The Agile Manifesto has as a central tenet, “We are uncovering better ways of developing software by doing it and helping others do it.” This approach to project budgeting is meant to provide one way that contract digital agencies can provide an experience as good as the manifesto envisions for clients.

Why agencies sell fixed-bid projects, and why they shouldn’t

Or, “How We Got Where We Are.”

Fjorge is not the only development company that’s fallen into the trap of defaulting to selling fixed-bid projects. It’s a very common practice among agencies to promise clients a specific budget, timeline, and feature set. As agencies, we believe clients will have more confidence in us if we can make guarantees and promises. We think clients want to hear one price for their project. We tell ourselves that the promise of earning a profit by delivering an under-budget project will motivate us to complete the project efficiently.

Sadly, approaches based on these ideas do not produce good software products.

A fixed-bid project is harmful to software quality

By selling a software project with a fixed budget, scope, and timeline, agencies do their clients a disservice. A single price on a build turns a client into a customer: they expect a product of a given caliber to come out of the other end of the development assembly line. A sort of “set-it-and-forget-it” approach to project planning and development.

But software development is complex. To gather enough information to make precise predictions of the level of effort required for every software feature requires a significant investment of technical expertise. Furthermore, by the time all of the discovery has been completed, digital technology evolves at such a rate that initial research can become outdated by the time final research is completed. All the while, the product only exists as an idea.

When you force an estimate for this type of work, the resulting experience for clients during development is unpleasant. Project managers request change orders once the original budget is exhausted to authorize an additional budget for the remaining features promised for the original budget. The development team resists feedback from the client during development that would change the scope of the project, which can result in a final product that doesn’t match the client’s needs. The development team avoids showing the client work-in-progress, for fear the client will want changes they didn’t budget for. The team misses deadlines trying to build all the originally discussed features. The client ends up with a product that cost more than they could afford that doesn’t meet their needs, late.

Software projects don’t finish early

I mentioned that one of the reasons fixed-bid projects are attractive to agencies is the potential for efficient, profitable completion. This is a more common idea on sales teams than operations teams for a simple reason:

Software product development is never done.

Software does not come off an assembly line fully-formed. You don’t throw it away when you’re done with it. Software is maintained, continually improved, and occasionally rebuilt.

Permit me another metaphor. Let’s say you need to move around your neighborhood faster than you can on foot. You can buy a Ferrari or a bike, and both get you from point A to point B. In software development, you can have a bike that becomes a Ferrari. What you need to avoid is building a Ferrari body with no engine, or a bicycle that needs to go 100 miles-per-hour.

If a project scope does get completed early, on a rare occasion a client might decide to finish the project and launch early. More likely, a client will look at their remaining budget and think, “I’ve got some other ideas.” An agency could hold the line and refuse to execute additional work outside the fixed scope of the project, but that’s frustrating to clients and generally results in inferior products. So what typically happens is, agencies complete more work until the project is over budget, and then the agency eats the overbudget cost.

It’s easier to understand one price on a build

This one’s just true. The reality is, clients generally have a certain amount of money they’re willing to invest in a software product. Depending on the client’s familiarity with software development, they might be savvy enough to authorize a smaller budget than the top of their range. But many clients won’t be aware of how rampant the overbudget problem is in software development. Agencies need to be better custodians of client budgets by structuring projects to evade the known issues plaguing contract software development.

Proposed Solution: The 70/30 Budget

At the risk of oversimplification, fjorge has found a solution that is keeping our clients and our staff happy. We should keep it a secret, but the truth is, we would rather be part of the industry solution to this widespread problem than use this approach for our own competitive advantage. The problem’s too big, and we have enough faith in our work quality to share this approach with the community.

Without further ado, here’s what you do:

1. Determine the client’s overall investment appetite. This is not easy to do, but it’s something software development sales staff and account managers often understand intuitively or through experience.
2. Determine the features the client wants. Each feature should be defined as functionality that can be added to the product to generate a complete, releasable product once added. (So, interfaces aren’t features, they are parts of features.)
3. Estimate all of a client’s features based on uncertainty. There are a variety of approaches to this, which this post won’t go into. Be sure to calculate your project overhead for each feature estimated.
4. Prioritize the features based on how important they are to the client’s business case. Often, this involves making an ROI determination and assessing dependencies between features.
5. For 70% of the client’s desired investment, grab features from the prioritized list until you’ve added as many high-priority features to the scope as you can without exceeding the 70% budget. This becomes your fixed project scope, and the 70% budget is the starting budget for the build. This budget will be used until it runs out. If the build is completed before this budget runs out, the client can launch early, or add in more features from their prioritized list. As the agency, you’re guaranteed to be able to bill for at least this price.
6. For the remaining 30% of the client’s desired investment, create a second project budget to be billed hourly, preapproved by the client. No features get assigned to this budget in advance. It’s a contingency budget that exists to protect the client from spending more than they can afford on a product build. If something unexpected comes up during the build, this budget is available to ensure that the product still meets the client’s business needs in the end. If the fixed budget doesn’t run out before the client is ready to launch, this budget is never triggered. If, after the fixed scope is complete, the client wants to spend their whole authorized contingency budget adding additional features, they’re entitled to do so. Both options yield a valuable product that meets the client’s budget needs.

Caveat: This is not magic, and it’s not going to protect you in 100% of projects. The key to successful product development is having someone on the agency side invested in your product’s success. But the combination of a Product Owner and the above approach is the key to successful contract software development.

Scenarios

Scenario 1: The agency completes the functional requirements of the project within the fixed budget ahead of schedule.

In this scenario, scope management has been so effective and collaboration has been so good that we complete the functional requirements according to the original estimate, maybe even a little bit early. The client has 100 hours left in their fixed project budget of 1500 hours, but they also have a functional product with the features they need to go to market.

This is a great position for a client to be in. They can decide to launch their product and start earning that anticipated ROI on their development investment, in which case they forfeit the 100 hours from the fixed budget. Win-win.

Forfeiting the budget might not be appealing, though — so instead of releasing, they decide they want to add a few more bells and whistles to their product. Great! They still have 100 hours left to add features before they release.

In either case, their project came in 30% below their anticipated budget because the contingency budget was never engaged.

This is an extremely rare scenario, but it does happen. It’s more likely when a client is very engaged in the development process, when feature complexity is relatively low, and when we both get lucky.

Scenario 2: The agency completes the functional requirements of a project in more time than the fixed bid project hours because a client or third-party doesn’t meet a few deliverable deadlines

In this scenario, one of the third-party partners owes a product dependency to the agency and misses a deadline. This can happen for any number of reasons: inadequate coordination, competing priorities…the list goes on. Software development is collaborative and complex and you need a solution for when things don’t go according to plan.

This is where the contingency budget approach shines.

Because the client preapproved this budget exactly for scenarios like this, the development project doesn’t get put on pause to sort out budget implications of the delay or the missed deadline. The client simply authorizes use of the contingency budget and developers continue to build features in their order of priority.

The functional requirements are completed using 80 of the 100 pre-approved contingency hours, and the client is able to launch their product.

Conclusion

If there’s one thing we’ve learned in the past year or so it’s the value of flexibility. However, it remains true that there’s only ever so much money available for development work. Developers want to build great, useful products that clients want. Sometimes the approaches we use to project planning stand in the way of that. This is one approach to changing the paradigm and finding new ways to deliver greater value to clients than traditional methods can, which is the central theme of agile software development.