Far Reach Core Value #6 is Learn and Grow. For us, this applies not only to our individual
skills, but also to how we work together with clients to produce great software.
One area that’s received pretty much continual attention over the years is how we bid projects. Our goal in this process is always to recommend an approach that maximizes value and minimizes risk for you, our client.
In this post, we’ll cover how we’ve learned to do this in a way that’s honest and straightforward, and that avoids as many unwelcome surprises as possible for all involved.
The Project Management Triangle
First, it’s important to understand the three interdependent variables present in every custom software project: cost, time, and scope. Changing one of these variables correspondingly affects the other two. For example, if the timeline
is short, the project’s scope must be smaller, so costs will go down because fewer features can be developed. Looking at it in a different way, if the scope of a project increases (i.e., more features are needed), it will take more time to complete,
which means the cost will increase.
These variables can change more than once in a project and that's fine as long as the triangle's integrity is not compromised (meaning, for example, the timeline shrinks, but the scope doesn't, resulting in a lopsided triangle).
The Problem with Fixed Bids
It’s not uncommon for clients to want a fixed bid or an exact cost for developing their software. The problem is that custom software projects are notoriously unpredictable. It’s simply not possible to know every detail before beginning, and
it doesn’t benefit anyone by pretending we can.
This reality leads to one of three possible outcomes with fixed bid projects.
In the first example, the developer pads her bid to account for all the things she doesn’t yet know at the start of a project. This padding can add up to a significant amount and can mean you end up paying way more than you should have. In this
case, you lose.
The second possibility is that the developer bases her bid on the best-case scenario, doesn’t pad her bid (or doesn’t pad it enough), and ends up losing money on the project. Here, the developer comes out on the short end of the stick. Too
many of these outcomes and the developer goes out of business (and along with the business goes the technical support for your application).
The last, and most common, scenario is an off-shoot of the second one. The bid does not account for unknowns so, when new information is learned or things change (and they inevitably will), the developer tries to minimize the amount of extra development
time required by cutting corners instead of focusing on delivering the best product to meet your goals. This degrades the quality of the software—potentially significantly—and you both lose.
Because of this, we don’t commit to fixed bids.
A Better Way
Over the years, our proposal process has become more focused on education than sales. We learn about your business or organization, your pain points and opportunities, your goals, and how you feel software can help.
In turn, we spend time educating you about our team, how we work and why we work that way, and the value we can bring to your project as consultants and developers.
Depending on the project, it’s typical for our business strategist and a lead developer to meet with you several times before starting in on a proposal. In addition to gaining an understanding of your needs and introducing ourselves, these meetings
are an opportunity for us to get to know each other and get a feel for whether or not we’re a good fit for each other.
As a client, you want to ensure we have the experience and expertise to help you, that we communicate in a way you understand, and that you’re comfortable with the way we work. We both want to be comfortable that we, as developers, fully understand
the problem you’re trying to solve or the opportunity you’re trying to capture, the high-level features to be included, and what your goals for the project are. And, most importantly, there needs to be some level of mutual trust. Without
trust, the chances of a successful outcome take a significant hit.
Armed with a good high-level understanding, we draft a proposal that demonstrates our understanding of the project and your goals, and describe our recommended approach to tackling your problem or opportunity and minimizing your risk.
Investment and Timeline
Initial investment and timeline estimates are included for our recommended approach, based on the information we know at the time. Typically, we lay out, at minimum, a discovery/analysis
phase, and likely also an initial development/deployment phase. With the limited information available to us at this early stage, it’s not possible for us to provide an exact cost. However, even these high-level estimates serve an important purpose—they enable you to make decisions about your budget and whether a custom solution provides
enough value to at least proceed with a discovery phase.
Lastly, our proposal outlines what happens after your project has launched. We go into every project with the intention of building a long-term relationship, so the value doesn’t end once the application is live. We want to ensure you understand
any potential ongoing costs and what you can expect from our team when it comes to the support you’ll receive.
Bidding is an Art
Bidding custom software projects is more art than science, but we’ve learned a lot over the years about what potential clients value during the process and have worked hard to make it as painless as possible for all involved.
Do You Need Custom Software?
Learn the signs.
Next time we’ll dig in to our approach to the analysis phase, so stay tuned. In the meantime, if you have a project to talk about, reach out.