Many clients like the idea of a fixed bid contract for software development because, from their viewpoint, it reduces risk by fixing the cost on the project. However, this is rarely the case, and requiring a fixed bid usually increases cost, and introduces a great deal of risk for the client, the developer, and increases the chances of complete project failure.

We’ll explain why this is the case, and why this concept is counterintuitive.

The Traditional Fixed-Bid Process

Traditionally, when an organization embarked on a software development journey, a team scoped the project in as much detail as possible and prepared an RFP with a requirement for a fixed cost for the project. At the surface, this seems sensible – let’s ask vendors to do their best job at estimating the project, and we’ll come to an agreement we can both live with.

The Waterfall method of development is typically fixed bid. With Waterfall, the entire project is scoped in detail, and a fixed development cost is given by the developer.

 

But fixed-price contracts for software development unfortunately gives a false sense of security, with a lot of negative consequences including:

Overbidding and Underbidding

The more complex a project is with a lot of unknowns introduces risk that has to be calculated. One way to mitigate this risk is by overbidding on the contract to hopefully cover those unknowns. This guessing game on the cost almost always results in one of two scenarios:

The client pays a lot more for the work than they should, because the developer is mitigating their risk by charging more for the project, often dramatically.
The developer loses money on the project because they underbid the project.

Rarely does it work out just right for both parties where the estimate hours came out to what was actually required. Someone almost always loses, and sometimes big.

Clients might think “If they bid too low, that’s their problem.” But when the developer underbids, they will be panicked as their costs soar, and start scrambling to minimize the hours by cutting corners, looking for upsells, and creating change orders constantly. The product suffers, or even fails completely. No one wins.

Even worse, a common and unethical practice some development teams use is to underbid the project knowing full well that they will be able to create profitable change orders.

Cost is Overweighted in Importance

Fixed-bid contracts encourage buying on price instead of quality and competence of the team. With fewer and fewer developers doing fixed bid contracts, it self-selects teams that are willing to take risks, which exposes the client and project to those risks.

Overscoping

To reduce risk, the scope documents become extremely detailed in order to set the project scope in stone. While there is nothing wrong with good scope documentation, it can become an adversarial situation when docs become a tool for scope creep gotchas for the developer, or for holding development teams feet to the fire by the client on project minutia.

Change Orders

Invariably, projects don’t go as planned – new ideas, obstacles, changes in business models and other factors can cause a project to pivot. When that happens, it can set up a conflict between the developer who wants to be paid for the change, and the client that thinks that was already in the scope. New ideas and concepts for doing things better are suppressed because bringing them to the table causes a round of change orders and potential disputes between the developer and the client.

The Budget Becomes Incompatible with Success

Ideally, what everyone should want is a successful launch of a great product that’s on time and within the budget. Fixed price contracts often result in the developer cutting corners to meet the deliverables, introducing technical debt (doing things for expedience to reduce cost but not necessarily with quality) that the client isn’t even aware of. Everything is done to complete the scope of work as closely as possible, which is not the same as creating the best possible product!

All these problems have the same root cause - by their nature, fixed bids set up an adversarial relationship between the developer and the client, each jockeying for the advantage, and mitigating their damages when things go wrong.

 

 

Agile - A Much Better Way to Manage Project Costs

In the 20 years or so that Agile development has been around, more and more companies and organizations are seeing the benefits of this approach. With Agile, clients are billed for all reasonable charges at an agreed hourly rate.

Agile Chart

We won’t go into all the advantages of Agile in this article, but we will focus on some of its key benefits, and particularly in how it can have a positive impact on managing projects:

Developer and Client Collaborate for the Best Result

Agile teams are naturally collaborative, working together to produce the very best product possible within the budget and timeline. Everyone is looking for how to do something better or faster that improves the user experience and the product overall. Each idea can be shared freely and review its impact on the product, the budget, and the timeline without negative consequences. It’s a part of the culture and team rituals that reinforce and welcome dynamic ebbs and flows for every initiative.

No Change Orders

The change order is a thing of the past! With Agile, the scope (the Epics, Stories and Acceptance Criteria) is important, but not at the expense of creating a better product. Changes are expected, planned for, and are a normal part of the development process. It’s impossible to pre-plan every single detail and rather than delaying or paying extra to over-plan, teams focus on the quality to deliver the solutions possible.

Problems are Managed Properly

The best laid plans… you know the rest. Everyone assumes things at the start of a project that just don’t go as planned no matter how much planning you do. In an Agile environment, issues and obstacles are brought up and discussed by the team as they occur and are mitigated and managed the right way. Various rituals reinforce this concept of reviewing, reinforcing, testing and matching criteria up with end-user feedback. There are no gotchas, and no finger pointing!

Technical Debt Isn’t Hidden

Technical debt is the concept of doing something that reduces time and cost but will result in likely having to redo it later. Imagine bad plumbing behind the walls with pipes that can burst at any time, but not knowing how or why because these elements are hidden. In comparison to fixed bids, technical debt is often introduced when development teams see their budget dwindling and a lot more to do.

However, technical debt is not always a bad thing, and sometimes it can be done strategically to get the product to market faster and to reduce cost in an earlier phase such as during an MVP (minimum viable product) build. With Agile, technical debt isn’t hidden, but done for the right reasons and with collaboration between the developer and the client. Technical debt is exposed and reviewed by all parties and reinforced by team rituals and reviews.

 

Managing the Budget in Agile

Kanban Illustration

OK, so this is where a lot of teams struggle. Not many companies and organizations have virtually unlimited budgets and asking, “How much is all this gonna cost?” is not an unreasonable question.

What the client sometimes hears when presented with Agile for the first time is this:
We can’t tell you what it will cost or how long it will take – just give us your monthly budget and we’ll get stuff done. It will be great. Trust us!”

While that’s a bit unfair, the truth is that purely Agile teams are great for larger clients, with big budgets and large teams building something huge.

So, how do smaller companies embrace Agile, and still get clarity on the budget? There is no reason that having solid planning and process around the budget can’t be done effectively. We’ll dig into this a bit more.

 

The Chicken or the Egg Budget Problem

Often the hardest part for the developer and the client is figuring out how to move forward and actually start the project. Because, by its nature, Agile initiatives don’t have a fixed budget, asking what something might cost is difficult to answer, but it’s still an important and not an unreasonable question to ask. Our team uses a two-leveled approach to help answer the potential budget question for business owners.

The WAG

We often start budget discussion with a process we affectionally call a WAG or Wild Ass Guess. Now it’s not really a WAG but rather a streamlined fact-finding process that allows us to give stakeholders a realistic budget range for their project as outlined. We say realistic budget, because while the WAG isn’t a true estimate or firm budget number, it allows the client to understand what the financial commitment will likely be with a high level of clarity.

So, exactly how do you perform a WAG estimate that makes sense? There are several elements that make the WAG better and more useful. We work with the client to create a baseline plan, identify potential risks and blindspots, and use our historical knowledge to create the WAG. The WAG process is very structured, and the more homework a client does, the more accurate the WAG will become.

And, generally speaking, this is enough for the client to make a decision to potentially move forward with the initiative. If they have $250k in their budget for the project, a $100k - $150k WAG range is enormously helpful. It answers the question, “Are we in the right ballpark, or should we take our ball and go home?”

Discovery / PI Planning

If the client wants to proceed then we move to the second budgeting phase which will call Discovery / PI Planning. We use the Scaled Agile Framework (SAFe) methodology which is a version of Agile that typically is used by larger enterprise-level development projects, elements which we have adopted for all our client initiatives.

One important aspect of SAFe is PI Planning, or Program Increment Planning. A Program Increment – the PI – runs 10 weeks (90 day window or quarter), broken into 5 x 2-week Sprints. An important aspect of PI Planning are the Committed Objectives and Roadmap, which is an outline of the business and technical goals the team intends to achieve in the upcoming PI.

During PI Planning we map out the development initiative, gathering details and generating documentation across various aspects such as:

If you want to learn more about our SAFe and PI Planning processes read our "The Anatomy for Successful Discovery Planning" blog.



Summary

Fixed bid software development is quickly going away as organizations of all sizes see the value in the Agile methodology, and that it greatly improves success when done correctly. And, for smaller organizations with limited resources, SAFe principles can give clarity and transparency to the budget, and help you manage your costs effectively. The essentials to learn are:

Image

Developing great digital products is our passion.

Not sure how to start that journey? Let us help you find the right path. Schedule a free 1-hour consultation with our team. At the end we’ll deliver a Project Brief that will help you to crystalize your vision.