Update! We've changed how we do project bids. Find out more about how we bid custom software projects now.
We’ve worked on a good number of custom software projects over the past five years. In the process, we’ve learned quite a bit about structuring these projects for success in order to minimize the stress and risk for our clients (and ourselves!)
The custom software development process we’ve fine-tuned over the years ensures a quality outcome, minus the project-derailing surprises along the way.
In this and an upcoming post, we’ll cover this process.
Today, we’re starting with project bids and why we do things the way we do. The first important point we need to make is this—and it may be obvious—custom software projects have three interdependent variables: scope, time, and cost. If the scope of the project increases, the time it takes to complete increases, which means cost goes up.
There’s no way around it.
At Far Reach, we don’t commit to fixed bids on custom software projects, and here’s why.
Custom software projects are not 100% predictable. Not even close. A fixed bid pretends they are and leaves you with these possible outcomes:
The developer loses out: Inevitably, unexpected discoveries come up or new ideas arise that would add real value to the product. Thus, the project takes more time than projected and the developer loses money—oo many of these, and the developer is out of business.
The client loses out: Experienced developers forced into a fixed bid situation will “pad” the bid, and often by quite a bit, because they know better and have no choice. In this instance, the client may end up paying more than necessary.
Both lose out: This, frankly, is the most common outcome. The developer is forced into a situation where she must focus on time spent rather than fully understanding the problems and their best solutions. The developer is forced to cut corners. The project maybe comes in at budget, but the product is inferior. No one wins in this situation.
We certainly don’t want our reputation tied to an inferior product.
And, above, we mention the possibility that the developer loses money on the project. Are you thinking that’s not a concern for the client? Think again. Custom software is just that—custom. No two developers would build a product in exactly the same way.
The same developer that builds the custom application is the same one you want maintaining it, if at all possible. It will save you money and hassle in the long run. For this reason, you want your developer to run a successful operation and be around for the long haul.
For these reasons, we charge our clients for the true effort that goes into creating their software, with clear communication about scope and budget along the way. We believe there’s no other way for a client to get their money’s worth, and for us to put out a product of which everyone involved is proud.
For every potential project, we begin with a proposal that offers a high-level estimate and confirmation that we understand the goals of the client. The estimate includes the following:
- Project management
- Business analysis
- Design
- Development
- Technical analysis / design
-Initial project setup
- Development / cutup
-3rd party license fees
- Unit testing
- Test site setup (if applicable)
- Deployment to production
This initial proposal gives the client a general idea of the potential budget of the project, and whether or not it makes sense to proceed. If the client decides to move forward, the next step is typically an analysis phase to further refine the scope of the project and the resources required.
Next time, we’ll cover the analysis phase more thoroughly, along with the rest of our development process and why it adds value to our projects.
Have you been involved in a custom software project as either a developer or client? What was your experience? We’d love to hear about it in the comments below.