Traditional Software Contracting Is Broken
“What are your requirements? Send me your full spec, and I will give you a quote.” If this is the first thing your prospective app company asks you to do, they are part of the fundamental problem with software development.
The Question Itself Is Backwards.
The question “what are your requirements?” is just backwards. Software is pretty complicated stuff, and there are a lot of moving parts that make requirements generation & management difficult. This makes writing good requirements tough for software people. Assuming that companies outsource software development because it is not a core competence, how could they be good at writing requirements?
Specs of any kind are also notoriously responsible for communication blunders. “Oh… I thought you meant blah de blah (because it was easier and cheaper for me to do it that way).” Specifications serve as a great internal check list to keep tabs on all the stuff that a team intends to build, but it is a terrible way to communicate vision or intent. Requirements as a basis for contracting also forces development shops to use a single-cycle waterfall method (design-build-test-release), which has been proven to fail in spectacular fashion.
Scope Does Not Determine Price!
Many development shops won’t admit this, but scope (as in what gets built) has very little to do with price. The exact same feature can be built many ways for many prices, and quite often the results are not any better one way or the other, they’re just better suited for different things. Without asking the question “why do you need this?” or “who will be using this?” you miss the opportunity to build what the client is actually asking for.
Price estimates are about efforts, not features.
The preconceived notion that scope determines price originates from marketing messages touting features as justification for cost. On the surface, it makes sense… If it can do more, then it must be harder to build, and it should cost more money. Although many companies have shown us that simple and elegant with a small feature set is terribly difficult to master (and more expensive as a result), we still find it hard to break the traditional thinking.
What if I were to tell you that we can do that same job for $15K or $30K and you can choose what it costs?
You might think that anyone choosing to pay double is a bit slow and is getting ripped off. However, the truth is that different people want the same feature set for different purposes, and have different expectations about the results. Higher expectations and better outcomes require more effort to get the job done. That is what drives price. This is an important fundamental premise, so I’ll say it again:
More effort and higher prices are required to meet higher expectations and produce better outcomes.
How Bidding Works
If a salesperson is asking for a scope document, they have their own best interests in mind. When reading through bullet lists and outlines, they are thinking “what is the most cost effective way we can get this done to maximize profit and send out a competitive bid?”. This seems innocent enough, but if you break it down logically, you get an equation like this:
Bid ($) = Effort (hrs) * Features (#) * Rate ($) * Profit (%)
Four variables in the equation above don’t change after a project starts:
- Bid is the price locked into the contract. Can’t change that one without springing hidden costs or change orders on the client. Doing either of these makes for unhappy clients.
- Features outline what the app is supposed to do, and are also locked into the requirements. See #1 for why they can’t change either.
- Rate is what the company needs to pay employees and rent. Can’t change that if you expect to run a legitimate business.
- Profit is what allows a company to cover cash flow in the short term and grow in the long term. That one can be squeezed a bit, but most companies will do anything to avoid it.
So that leaves “Effort”. Since the requirements can be checked off in so many ways, the shortcuts start to creep in as the project budget runs thin. Unexpected difficulties cause original estimates to fall short, and those estimates were optimistic in the first place to produce a competitive bid. In extreme cases, companies might cut losses, cancel the project, and run with the payments already made. In all these cases, however, the client is left with a crappy app and a crappy experience.
This Is Nothing New
Software contracting has been broken for decades, so this is nothing new or insightful. However, nobody seems to be able to do much about it. To date, there have been a number of inadequte attempts at avoiding the budget problems:
- Overestimate costs. Charging more money from the start makes sense to many companies because it has no project execution downside. When budget is left over, money gets pushed over to profit — yay! Of course, you need to pay more for marketing and sales to generate work. More jobs & bigger companies are the result, which is good for the economy. However, the clear loser here is the client who pays too much, and the would-be products that never get created because development is cost-prohibitive.
- Use hourly rates. Throwing it all out the window, some shops just work hourly and make no promises about total cost. Common practice also seems to be estimating hours for “not-to-exceed” contracts that always exceed. Hourly arrangements also take more sales and marketing dollars to demand higher rates, or companies can go the opposite route and reduce rates by hiring less skilled resources. Again, this is a terrible experience for the client because they are expected to understand software estimates, judge talent, and manage efforts. If they can do all of this effectively, why would they need to outsource?
So, What Can We Do?
Many companies do a fine job with internal software development. Let’s assume we’re talking about the ones that produce good software with:
- Customer-driven planning
- Multiple iterations of development
- Quality feedback and change mechanisms
Many companies accomplish this with project budgets, so it’s not a huge leap to propose that this process can be outsourced with contracts.
It can, and here’s how...
A software development company operating in a focused space (like web & mobile apps) can rely on experience to identify a budget that works for all projects. These budgets correspond to a fixed amount of effort, so the price tag can be fixed as well (giving the client peace of mind). An experienced team can manage the project so that the right amount of time is spent on planning, concepts, graphics/UX, and launch preparation. The ratio of time spent in each of these stages might vary slightly, but the total effort (and cost) stays fixed.
The variable with this type of agreement is scope, and the number of features can change freely through the project. The first order of business is to identify the core feature set with customer-driven planning so the right features are chosen. Concept apps are then built with iterations so effort can be tightly tracked and controlled. Features that are not completed in the allotted amount of time are moved to the next phase of development. The final concept is then polished and prepped for launch with the remaining time.
The key is to cut off new features and suppress scope creep so that the polish & prep does not get pushed back. Many projects get derailed because there is always one more thing that is seen as a “must-have” even though it does not support the original customer-driven objectives. Ever hear that the last 10% took 50% of the time? Strong management (and deep experience) is needed to ensure this does not happen and the project stays on track.
This works, and it works well. The challenge is getting people to understand it. Decades of conditioning tell us that we pay for features, and anything else is just somebody trying to take advantage! Maybe if we all worry a bit less about protecting ourselves with rigid contracts, and worry a little more about the products we’re trying to build together, things would work out better.